Angular 5中ng serve首次编译失败，后续保存编译成功的问题咨询

嘿，我之前在Angular 5开发时也碰到过这个一模一样的情况，来给你拆解下这个现象的原因、解决办法，以及它到底是不是预期行为：

原因分析 #

本质上是Angular CLI在两种编译场景下的策略差异：

• 首次执行ng serve时，会触发全量严格编译，它会扫描所有代码并强制执行完整的TypeScript类型检查，只要存在像[ts] Property 'x' does not exist on type 'y'这类类型错误，就会直接阻断编译，输出webpack: Failed to compile。
• 而当你修改文件并保存触发热重载时，CLI为了提升开发效率，启用了增量编译机制——只重新编译修改的部分，同时默认对非致命的类型检查错误（不影响JavaScript转译的错误）放宽了限制。简单说就是，热重载优先保证编译速度和开发流畅性，暂时忽略了类型检查的报错。

解决办法 #

如果你希望热重载时也严格执行类型检查，或者想彻底解决这个差异，有几个方案可选：

• 严格配置TypeScript编译规则
  打开项目根目录的tsconfig.json，确保以下配置项设置正确：

  {
    "compilerOptions": {
      "strict": true, // 启用所有严格类型检查选项
      "noEmitOnError": true // 只要有错误就不生成编译产物
      // 其他原有配置...
    }
  }
  

  这样无论首次编译还是热重载，只要存在TypeScript错误，编译都会失败，保持一致性。

• 强制Angular CLI在开发服务中启用严格模式
  修改angular.json里的项目配置，在architect -> serve -> options中添加"strict": true：

  {
    "projects": {
      "你的项目名称": {
        "architect": {
          "serve": {
            "options": {
              "strict": true,
              // 其他原有配置...
            }
          }
        }
      }
    }
  }
  

  或者直接在启动命令里添加参数：ng serve --strict，这样开发服务器会全程严格执行类型检查。

• 从根源解决：修复TypeScript错误
  最彻底的方式当然是直接修正那些类型错误，比如给对应的类/接口添加缺失的属性，或者使用类型断言（const obj = someObj as TargetType）来明确类型，从根本上消除这类报错。

是否属于预期行为？ #

答案是是的，这是Angular CLI在开发模式下的有意设计。开发过程中，开发者经常会写一些临时代码或者还没完善类型的片段，热重载时放宽类型检查限制，能让你快速看到代码运行效果，不用每次都因为类型错误被卡住。但如果你需要更严谨的开发环境，就可以通过上面的配置来调整这个行为。

内容的提问来源于stack exchange，提问作者Ben