Angular 22.0.6 已发布。这不是一次带来新 API 的大版本，而是更典型的补丁版本：修编译器边界、修 compiler-cli 对 signal 写法的诊断与转换、修 forms/signals 的兼容性问题。对业务项目来说，这类版本最值得关注的不是“有没有新功能”，而是它是否能减少模板类型检查、信号绑定和表单迁移中的误报或边缘行为。
这次修复集中在哪些地方
本次更新里，compiler 修复了 TCB 中安全函数调用的实现方式：在 Type Check Block 里使用常规的可选链式表达式来实现安全调用。TCB 是 Angular 模板类型检查背后的生成代码，开发者通常看不到它，但它会直接影响模板里 user?.getName?.() 这类表达式的类型推断和报错质量。
compiler-cli 侧有两项信号相关修复值得看：
- 对所需的 signal query 应用
debugName转换。 - 使用三元运算符检测绑定表达式中未调用的 signal。
这说明 Angular 仍在继续打磨 signal 进入模板、查询和诊断链路后的细节。尤其是“未调用的 signal”诊断，对团队迁移到 signal 写法时很实用：很多问题不是运行时报错，而是模板里把 signal 当普通值用了。
forms/signals 也有兼容性修复，摘要里提到是为了兼容 Abstract... 相关接口或行为。由于源摘要被截断，这里不展开具体 API 结论；更稳妥的做法是把它视为表单信号化路径上的兼容补丁，升级后重点跑表单相关测试。
TCB 修复为什么会影响日常开发
Angular 的模板并不是直接由 TypeScript 编译器检查。Angular 会为模板生成类型检查代码，也就是 TCB，再交给 TypeScript 做静态分析。因此，一个很小的 TCB 生成差异，可能会表现为：
- 模板里安全调用报错不准确。
- 可选链表达式推断过窄或过宽。
- 严格模板检查下出现难以解释的错误。
可以这样理解这次 compiler 修复：Angular 在 TCB 里更贴近 TypeScript 原生可选链语义，减少安全函数调用场景下的类型检查偏差。
业务代码里常见的安全调用如下：
// profile.component.ts
import { Component, input } from '@angular/core';
type User = {
name?: string;
formatName?: () => string;
};
@Component({
selector: 'app-profile',
standalone: true,
template: `
<p>{{ user()?.formatName?.() ?? user()?.name ?? 'Anonymous' }}</p>
`,
})
export class ProfileComponent {
user = input<User | null>(null);
}
升级到 22.0.6 后，可以重点观察这类模板在 strictTemplates 开启时的诊断是否更稳定。
Signal 绑定：别忘了在模板里调用它
Angular signal 的一个常见坑是：在 TypeScript 里 signal 是函数式读取，模板里也应当通过 count() 取值。如果写成 count，你拿到的是 signal 本身，而不是 signal 当前值。
本次 compiler-cli 提到“使用三元运算符检测绑定表达式中未调用的信号”，这意味着类似下面的模板表达式会更容易被识别出来：
// counter.component.ts
import { Component, signal } from '@angular/core';
@Component({
selector: 'app-counter',
standalone: true,
template: `
<!-- 推荐：调用 signal 读取值 -->
<button [disabled]="count() > 10">
Count: {{ count() }}
</button>
<!-- 可以这样检查迁移代码：三元表达式里也要调用 signal -->
<p>{{ count() > 0 ? 'Started' : 'Idle' }}</p>
`,
})
export class CounterComponent {
count = signal(0);
}
需要排查的错误写法通常长这样：
<!-- 错误示例：count 是 signal 函数，不是当前数字值 -->
<p>{{ count > 0 ? 'Started' : 'Idle' }}</p>
这类问题在大型迁移里很隐蔽，因为模板表达式看起来“像普通字段访问”，但语义完全不同。
可以这样升级并做一次低成本验证
如果项目已经在 Angular 22 上，补丁升级通常可以直接走包管理器。下面以 npm 为例：
npm install @angular/core@22.0.6 @angular/compiler@22.0.6 @angular/compiler-cli@22.0.6 @angular/forms@22.0.6
npm test
npm run build
如果项目使用 Angular CLI，也建议保持 CLI 与框架版本一致或至少处于兼容区间：
npm install @angular/cli@22.0.6 --save-dev
npx ng version
npx ng build --configuration production
建议同时确认 tsconfig 中的严格模板检查配置。没有开启的话，这类 compiler/compiler-cli 修复带来的价值会打折：
{
"angularCompilerOptions": {
"strictTemplates": true
}
}
升级后可以重点跑三类用例：
- 模板里使用
?.()的安全函数调用。 - signal 在插值、属性绑定、三元表达式中的读取。
- 使用 Angular forms 或 forms/signals 的表单页面。
采用建议：补丁版本也要按风险面验证
Angular 22.0.6 适合已经进入 Angular 22 的项目尽快评估。它修的是编译器和诊断链路，不太像业务 API 变更那样显眼，但影响的是“构建时能不能准确告诉你哪里错了”。
升级时不要只看应用能否启动。更可靠的检查清单是：开启严格模板检查，跑生产构建，跑表单测试，搜索模板里的 signal 未调用写法。对正在从传统字段迁移到 signal 的团队，这个补丁尤其值得纳入日常依赖更新窗口。