JavaScript 的灵活性和广泛适用性并不意味着它无所不能，也并非在所有场景下都是最优选择。了解它的局限，才能在技术选型和日常开发中做出明智的判断。
单线程不适合 CPU 密集型任务
JavaScript 主线程只有一个，这意味着它擅长处理 I/O 密集型的并发（大量网络请求、文件读写），但在面对 CPU 密集型计算时（如大规模图像处理、视频编解码、复杂加密解密、海量数据循环）会暴露出短板。一个长时间运行的同步循环会直接阻塞整个页面或服务器的事件循环，导致用户界面无响应，或者后续请求全部排队等待。
解决思路不是放弃 JavaScript，而是：
- 将计算密集任务交给 Web Worker（浏览器端）或 Worker Threads（Node.js 端），在独立线程中执行。
- 对超大任务进行时间切片，使用
requestIdleCallback或分段执行，避免一次性长时间占用主线程。 - 对于极端计算场景（游戏引擎、3D 渲染、音视频处理），可以结合 WebAssembly 来获得接近原生的性能。
动态类型带来的运行时不确定性
缺乏编译阶段的类型检查，意味着很多错误只能等到代码真正执行到那一行才会暴露：
const user = { name: "张三" };
console.log(user.age.toFixed(2));
// 运行时才发现 age 是 undefined，调用 toFixed 直接报错在小型项目中这种灵活性是优势，但在大型多人协作项目中，它极易导致隐蔽的 bug。正因如此，TypeScript 应运而生——在编写阶段提供类型检查，将大量低级错误消灭在开发阶段。对于中型以上项目或团队协作场景，建议优先考虑 TypeScript。
依赖浏览器宿主环境的能力边界
JavaScript 运行在浏览器的沙盒环境中，不能直接访问操作系统层面的资源：无法随意读写本地文件系统、无法直接访问硬件设备、不能随意与其他进程通信。虽然浏览器提供了 Web API（如 File API、Web USB、Web Bluetooth）来扩展能力，但这些 API 需要用户主动授权，且受同源策略等安全机制的限制。
这意味着纯粹的浏览器端 JavaScript 应用在功能上永远不及原生桌面应用那样自由。Electron 等方案通过引入 Node.js 运行时补充了这些能力，但也带来了更大的应用体积和更高的内存占用。
npm 生态繁荣背后的隐忧
在享受海量包带来的便利时，也需要正视三个现实问题：
- 依赖地狱：一个项目可能间接依赖数百甚至上千个包，版本冲突时有发生。锁文件（lockfile）是基本保障，但定期审计和更新依赖依然是必要工作。
- 安全风险：恶意包、供应链攻击屡见不鲜。
npm audit能发现已知漏洞，但不能保证新引入的包完全可信。引入依赖前查看其下载量、维护频率、GitHub 活跃度，是一种务实的防御习惯。 - 包体积膨胀：一个简单的工具函数也可能引入庞大的依赖树，导致前端打包体积激增。学会分析打包产物（借助 webpack-bundle-analyzer 等工具）并按需引入，是前端性能优化的基本功。
跨平台不等于零成本
虽然 JavaScript 可以运行在多个平台，但“一次编写，到处运行”在实践中需要额外的工作：
- 不同浏览器的 API 支持程度仍有差异（尤其 Safari 和旧版 IE），Polyfill 和 Can I Use 的查询是日常操作。
- Node.js 与浏览器的全局对象不同（
windowvsglobal，document是否可用），编写同构代码时需要环境判断。 - React Native 等跨平台方案只是“学习一次，到处编写”，UI 层依然需要针对不同平台做适配。
不是什么都能做，也别什么都要做
任何技术都有其适用边界。JavaScript 适合 Web 应用、中小型服务端 API、跨平台客户端工具；但在操作系统内核、高性能游戏引擎、实时金融交易系统等场景下，C/C++、Rust、Java 等语言有不可替代的优势。技术选型的智慧不在于背弃其他语言，而在于在合适的位置使用合适的技术栈，JavaScript 可以在它擅长的领域发挥最大价值，与其他技术协同构建完整的解决方案。
理解了这些局限，你就不会对 JavaScript 抱有不切实际的期待，也不会在遇到问题时迷失方向。接下来，我们将进入具体的运行环境和开发实践，看看如何在真实场景中用好这门语言。