ng server会启动哪个服务器？如何查看服务器配置

ng serve 启动的不是 Apache 或 Nginx，而是 Angular 内置的 webpack-dev-server，一个专为开发调试设计的 Node.js 临时服务器，默认跑在 localhost:4200 端口。它只在内存里编译打包，不生成物理文件，这也是很多人第一次接触 Angular 时最困惑的地方：明明启动了服务，磁盘上却找不到输出的 dist 目录。

Angular 开发服务器是什么？

ng serve 本身就是 Angular CLI 暴露出来的一个命令，当你敲下这行命令，CLI 会在后台帮你拉起一个基于 webpack-dev-server 的开发服务器，这个服务器的工作方式跟传统 Web 服务器完全不同：

• 传统服务器（Apache、Nginx）把磁盘上的静态文件通过 HTTP 协议吐给浏览器。
• 开发服务器把源码在内存中完成打包,然后通过 WebSocket 与浏览器建立双向通道，实现热模块替换（HMR）你改一行代码，浏览器不刷新页面就能看到变化。

这一机制决定了它不是一个“能上线”的服务器，它没有经过安全加固，没有启用缓存策略，也不支持多进程并发，它存在的唯一目的，就是让本地开发变得顺畅。

ng serve 默认端口和主机配置

为什么默认是 4200？

Angular 团队选 4200 没有官方说明，但在社区里已经形成一个认知：4200 不会被常见的后端框架占用，Java 系常用 8080，Node.js 常用 3000，Python 常用 8000，PHP 常用 80，4200 恰好避开了这些默认配置，冲突概率比较低。

如果你同时开多个 Angular 项目，第一个跑在 4200，第二个会自动跳转到 4201，以此类推，这是 CLI 检测到端口被占用时的自动处理机制。

ng serve 端口怎么改？

两种方式：

1. 命令行直接指定：ng serve --port 4300
2. 改 angular.json 配置文件，在 serve 节点下加：

"serve": {
  "builder": "@angular-devkit/build-angular:dev-server",
  "options": {
    "port": 4300
  }
}

命令行参数优先级高于配置文件,所以如果你两个地方都设置了，最终生效的是命令行参数。

想让局域网内别人访问怎么办？

默认情况下 ng serve 只绑定 localhost，也就是说只有你自己这台电脑能访问，如果你想用手机调试，或者给同组的同事预览效果，需要加上 --host 0.0.0.0：

ng serve --host 0.0.0.0

这样服务会监听所有网卡接口,别人通过 http://你的局域网IP:4200 就能访问，注意 Windows 防火墙可能拦截，需要手动放行 Node.js 的入站规则。

修改默认浏览器？

ng serve 默认不会自动打开浏览器，如果你希望启动后自动弹出页面，用：

ng serve --open

这台启动的服务器本身跟浏览器无关,它就是一个 HTTP 服务，只是会监听一个文件变化的事件通道，然后向所有连上来的客户端推送更新，浏览器只是其中一个客户端。

ng serve proxy 代理配置解决跨域

开发中遇到跨域问题是家常便饭,前端页面跑在 4200，后端接口跑在 8080，直接发请求必然被浏览器拦截，这时候有两个选择：

• 后端开启 CORS 头。
• 用 ng serve 自带的代理功能。

代理配置是更通用的做法,且不需要后端配合，在项目根目录创建 proxy.conf.json：

{
  "/api": {
    "target": "http://localhost:8080",
    "secure": false,
    "pathRewrite": {
      "^/api": ""
    }
  }
}

然后启动时带上代理配置：

ng serve --proxy-config proxy.conf.json

这样做的好处是：你的接口请求依然写相对路径 /api/xxx，开发服务器接收到请求后，会以服务端身份转发到 8080。此过程完全不经过浏览器，因此不存在跨域问题。

行业共识认为,前端路由使用 HTML5 History 模式时需要回退支持，开发服务器一般默认开启了对 historyApiFallback 的支持，而代理配置里你通常不太需要管这一块，用手头的项目做几次转发测试就能感受到差异。

ng serve 打包出的东西去哪里了？

这是新手最容易踩坑的点,运行 ng serve 之后，你去项目目录下找 dist 文件夹，找不到。

因为开发模式是内存编译,所有打包产物都在内存里，通过 HTTP 响应返回给浏览器，你关掉终端，内存释放，代码不会留下任何痕迹。

如果你需要生成物理文件,必须用构建命令：

ng build

执行完毕后 dist 目录才会出现编译后的文件，行业共识认为，ng serve 做到的是“感知上的速度”，它通过增量编译和缓存机制让二次启动和保存后的刷新都保持极快响应。

ng serve 生产环境可以用吗？

直接回答：不能。

原因有几点：

• 没有代码压缩和混淆,文件体积比生产包大数倍。
• 没有关闭调试工具和详细错误提示,暴露源码结构风险。
• 没有静态资源缓存策略,每次请求都重新编译。
• 开发服务器依赖 Node.js 环境，而生产环境通常用 Nginx 或 CDN 提供静态文件服务。

你在部署 Angular 应用时，需要先 ng build --prod，然后把 dist 目录里的文件放到任意一个静态服务器上。

下面用表格对比几种服务器在 Angular 场景下的定位：

与构建产物的关系

有经验的开发者会把 ng serve 和 ng build 看作两个完全独立的流程。

• ng serve 是开发时用，代码改动即时生效。
• ng build 是发布时用，输出一套优化过的最小化资源文件。

两者共用同一套源代码和构建配置,但优化策略完全不一样，据统计，一个中等规模的 Angular 项目，生产构建产物对比开发模式体积能缩小 70% 以上，这个数字因项目依赖多少而变化，但结论是稳定的：ng serve 只为效率而生，ng build 只为生产而生。

常见故障排查

端口 4200 已被占用

系统提示 Port 4200 is already in use，有两个办法：

1. 换一个端口：ng serve --port 4201
2. 杀掉占用进程：Windows 下 netstat -ano | findstr :4200 得到 PID，再 taskkill /F /PID 进程号；macOS/Linux 下用 lsof -i :4200 找到 PID，再 kill -9 PID

热更新失效怎么办

多数情况下是文件监听机制不兼容,Windows 上使用某些云同步盘目录，解决办法是让 Angular 使用轮询监听：

ng serve --poll=2000

这会每 2 秒检查一次文件变化，虽然性能开销略高，但兼容性最好。

修改代码后浏览器没刷新

优先检查控制台是否有编译报错,如果编译成功但页面没变化，可能是第三方库被缓存了，此时手动刷新页面或者在 main.ts 中强制关闭缓存策略再试一次。

为什么 Edge 打开页面空白而 Chrome 正常？

这种情况常出现在使用较老版本 Angular CLI 或自定义 webpack 配置的项目中，开发服务器默认输出的是 ES2015 以上的 JavaScript 语法，部分浏览器未能完整支持，多数情况下，升级 CLI 版本或添加 browserslist 配置即可解决，如果仍在排查阶段，可以在 angular.json 的 build 选项里调整 target 为 es5 观察反馈。

ng serve 速度很慢怎么办

大型项目冷启动时间确实长,业内专家指出，影响编译速度的核心瓶颈在于 TypeScript 类型检查和代码分包策略。

几个可落地的提速手段：

• 使用 @angular-devkit/build-angular 的缓存能力，CLI 本身已经默认开启持久化缓存。
• 拆分成多个懒加载模块,首屏只编译入口文件。
• 本机内存尽量扩展到 16G 以上，开发服务器在压缩代码时比较吃内存。
• 升级 Angular 17 以上的新版本，新版本使用 esbuild 加持的构建管线，启动速度有显着提升。

Q&A：ng serve 端口和服务器

ng serve 端口怎么改才能一直固定？

上面已经给出了命令和配置文件的两种方式,长期固定建议直接改 angular.json，这样任何成员拉下代码跑 ng serve 都对同一端口生效，不需要互相传达端口信息。

ng serve 和 node server 启动的文件服务器有什么区别？

node server 通常指你用 Express 或 Koa 自己写的一个静态文件服务，它需要你手动指定静态目录、处理路由回退、设置缓存头，ng serve 把这些全部自动化，并且额外提供热更新和编译功能，自己写 node server 更灵活，但需要维护成本，且没有编译能力。

ng serve 能否对接简米云或酷番云的服务器？

运营层面实际情况是：只要你在云服务器上装好 Node.js 和 Angular CLI，把项目代码传上去，在服务器上执行 ng serve 并绑定 0.0.0，通过安全组开放 4200 端口，外部就能访问，但这只适合临时演示，正式域名和备案流程不需要变，只是没法获得云厂商的 CDN 和负载均衡加持，生产环境依然建议构建后部署到 Nginx，无需在服务器上常驻 Node.js 进程。