2025年8月09日·1 分钟
为什么 Angular 在大型应用中推崇结构与约定
Angular 倾向于用结构化与约定来帮助大型团队构建可维护的应用：一致的模式、工具链、TypeScript、依赖注入和可扩展的架构。
在 Angular 中“结构与约定”是什么意思
Angular 常被描述为 有意见的（opinionated）。在框架语境下，这意味着它不仅提供构建模块——还推荐（有时会强制）具体的组装方式。你会被引导采用特定的文件布局、模式、工具和约定，这样即便不同团队构建的两个 Angular 项目也会有相似的“感觉”。
有意见并不等于“限制”——而是“决断”
Angular 的这些意见体现在如何创建组件、如何组织功能、默认如何使用依赖注入以及通常如何配置路由。与其让你在多种相互竞争的方案中选择，Angular 缩小了推荐选项的范围。
这种权衡是刻意为之：
- 更少决策负担： 你可以少花时间争论架构、文件夹结构、状态边界或构建配置。
- 更少自由度： 如果你非常偏好另一种风格，Angular 可能会让你觉得有阻力。
为什么大型应用更重视一致性而非灵活性
小型应用可以容忍实验：不同的编码风格、为同一任务使用多种库，或随时间演化的临时模式。大型 Angular 应用——尤其是那些多年维护的应用——为这种灵活性付出的代价很高。在大规模代码库中，最难的问题往往是协调问题：如何让新人快速上手、快速审查拉取请求、在重构时保证安全，以及让众多功能协同工作。
Angular 的结构旨在让这些活动变得可预测。当模式一致时，团队可以自信地在不同功能间切换，把更多精力放到产品工作上，而不是重复学习“这一部分是怎么做的”。
本文将覆盖的内容
接下来的文章将拆解 Angular 的结构来自何处——它的架构选择（组件、模块/独立组件、DI、路由）、工具链（Angular CLI），以及这些意见如何支持团队协作和大规模长期维护。
为什么大型应用会推动框架走向约定优先
小型应用能在很多“行得通就好”的决策下幸存。大型 Angular 应用通常不能。一旦多个团队共同维护同一代码库，微小的不一致会累积成真实成本：重复的工具函数、略有差异的文件夹结构、相互竞争的状态管理模式，以及三种处理同一 API 错误的方法。
团队扩展：防止代码漂移
随着团队扩大，人们自然而然会复制身边看到的实现。如果代码库没有清晰地指示首选模式，结果就是代码漂移——新功能遵循的是最后一个开发者的习惯，而不是共享的做法。
约定减少了每个功能需要做出的决策数量。这缩短了入职时间（新员工在你的仓库中就能学会“Angular 的方式”），并降低了审查摩擦（少了诸如“这不符合我们的模式”之类的评论）。
长期存续的应用：为变化优化
企业前端很少是“做完就不管”的。它们经历维护周期、重构、重设计和持续的功能变更。在这种环境中，结构更像是求生之道而非美学：
- 可预测的文件组织让所有权和导航更简单。
- 一致的边界让重构更安全（你知道逻辑应该放在哪里）。
- 标准模式减少了需求变更时的返工。
横切关注点在没有标准时无法扩展
大规模应用不可避免地共享横切关注点：路由、权限、本地化、测试以及与后端的集成。如果每个功能团队都以不同方式解决这些问题，你最终会在调试交互上浪费时间，而不是构建产品。
Angular 在模块/独立组件边界、依赖注入默认行为、路由和工具链方面的意见，旨在默认让这些关注点保持一致。回报很直接：更少的特例、更少的返工，以及多年来更顺畅的协作。
组件模型：可预测的构建块
Angular 的核心单元是组件：它是具有清晰边界的自包含 UI 单元。当产品变大时，这些边界防止页面变成“所有东西都互相影响”的大文件。组件让你明确一个功能所在、它负责什么（模板、样式、行为）、以及它如何被复用。
模板 + 类：一个职责，两部分
组件分为模板（描述用户所见的 HTML）和类（用 TypeScript 保存状态和行为）。这种分离鼓励呈现与逻辑之间的清晰划分：
- 模板专注于渲染和绑定。
- 类专注于数据、事件处理和协调。
// user-card.component.ts
@Component({ selector: 'app-user-card', templateUrl: './user-card.component.html' })
export class UserCardComponent {
@Input() user!: { name: string };
@Output() selected = new EventEmitter\u003cvoid\u003e();
onSelect() { this.selected.emit(); }
}
\u003c!-- user-card.component.html --\u003e
\u003ch3\u003e{{ user.name }}\u003c/h3\u003e
\u003cbutton (click)=\"onSelect()\"\u003eSelect\u003c/button\u003e
Inputs/Outputs = 可预测的数据流
Angular 推崇一个直观的组件间契约：
@Input()把数据从父传到子。@Output()把事件从子发到父。
这个约定使数据流很容易推理，尤其在大型 Angular 应用中，多支团队会触及相同界面。打开一个组件时，你可以快速辨别：
- 它期望什么数据
- 它可能发出哪些事件
- 它负责渲染什么
有助于团队加速的约定
由于组件遵循一致的模式（选择器、文件命名、装饰器、绑定），开发者能一眼认出结构。这个共享的“形状”减少了交接摩擦，加速了审查，并让重构更安全——无需每个人记住每个功能的定制规则。
模块与功能组织以支持扩展
当应用增长时，最难的问题往往不是写新功能，而是找出把它们放在哪里并理解谁“拥有”它。Angular 倾向于结构化，以便团队可以在不停地协商约定的情况下继续前进。
NgModules 与 standalone：两种划分边界的方式
历史上，NgModules 把相关组件、指令和服务组合成功能边界（例如 OrdersModule）。现代 Angular 也支持独立组件（standalone），它们减少了对 NgModules 的需求，同时仍通过路由和文件夹结构鼓励明确的“功能切片”。
不论哪种方式，目标都是一致的：让功能易于发现并使依赖有意为之。
按功能分组支持所有权与导航
一种常见且可扩展的模式是按功能组织，而不是按类型组织：
features/orders/（订单相关页面、组件、服务）features/billing/features/admin/
当每个功能文件夹包含了大部分所需内容时，开发者可以打开某个目录并迅速理解该区域的工作方式。这也很自然地映射到团队所有权：“Orders 团队负责 features/orders 下的所有内容”。
Core vs Shared vs Feature（以及“万能 shared 模块”陷阱）
Angular 团队常把可复用代码拆分为：
- Core： 应用范围的单例与基础设施（认证、拦截器、全局服务）。
- Shared： 多个功能复用的 UI 片段和工具函数。
- Feature： 领域特定逻辑，不应随意泄露。
常见错误是把 shared/ 变成垃圾场。如果“shared”导入了所有东西且人人都引用“shared”，依赖会纠缠在一起，构建时间会增长。更好的做法是让 shared 保持小、聚焦并且低依赖性。
Angular 如何推动一致性
在模块/独立组件边界、依赖注入默认设置和基于路由的功能入口点之间，Angular 自然地把团队推向可预测的文件夹布局和更清晰的依赖图——这些都是使大型 Angular 应用可维护的关键要素。
依赖注入作为默认架构
从清晰架构开始
使用规划模式在生成代码前理清路由、角色和数据。
Angular 的依赖注入（DI）不是可选附加项——它是期望的连接方式。与组件内部自行创建助手（new ApiService()）不同，组件请求所需内容，Angular 会提供正确的实例。这鼓励了 UI（组件）与行为（服务）之间的清晰分离。
为什么 DI 比“直接 import + new”更适合扩展
DI 在大型代码库中带来三方面便利：
- 测试： 在测试中提供假实现或 mock，无需改动生产代码。
- 替换实现： 同一组件在生产中使用真实 API 服务，开发或演示时可用内存版本替代。
- 复用与一致性： 像认证这样的共享服务可以在多个功能间复用而不重复逻辑。
因为依赖在构造函数中声明，你可以快速看到一个类依赖什么——在重构或审查陌生代码时非常有用。
服务作用域：root vs 功能级（以及避免“隐藏单例”）
服务的提供位置决定生命周期。在 root 提供（例如 providedIn: 'root'）会成为应用范围的单例——适合跨切面关注，但如果悄然积累状态就很危险。
功能级提供会创建作用域在该功能（或路由）内的实例，能防止意外的共享状态。关键是要有意图：有状态的服务应有明确的所有权，避免因为单例而产生的“神秘全局”数据存储。
在 Angular 应用中常见的服务角色
典型的 DI 友好服务包括 API/数据访问（封装 HTTP 调用）、auth/session（令牌、用户状态）和 logging/telemetry（集中错误上报）。DI 在不把这些关注点纠缠进组件的前提下保持它们的一致性。
路由与懒加载作为扩展策略
Angular 把路由视为应用设计的一等公民，而不是事后的补丁。在应用超过几屏幕时，这种意见就很重要：导航成为每个团队和功能都要依赖的共享契约。有中央 Router、一致的 URL 模式和声明式路由配置后，“你在哪儿”以及用户在移动时应发生什么都更易推理。
懒加载：性能与团队边界
懒加载让 Angular 仅在用户实际导航到某功能时再加载那部分代码。直接收益是性能：初始包更小、启动更快、对从未访问某些区域的用户节约资源。
长期收益是组织层面的。当每个主要功能有自己的路由入口时，你可以把工作拆分给不同团队并明确所有权。某个团队可以演进其功能区（以及内部路由），而不用频繁触碰全局 wiring——从而减少合并冲突和意外耦合。
守卫与解析器带来可预测的流程
大型应用常常需要围绕导航的规则：认证、授权、未保存变更、功能开关或所需上下文。Angular 的路由守卫把这些规则在路由层显式化，而不是散落在组件中。
解析器通过在激活路由前获取所需数据来增加可预测性。这有助于避免页面半准备好的渲染，并把“这个页面需要哪些数据”纳入路由契约——对维护和入职非常有用。
有助于扩展的路由结构
一种适合扩展的做法是基于功能的路由：
- 保持一个小且稳定的“外壳”路由配置（例如
/admin、/billing、/settings）。 - 把每个区域懒加载到自己的功能模块，并配备自己的路由文件。
- 把功能路由放在功能代码附近，使变更不会牵连整个仓库。
这种结构鼓励一致的 URL、清晰的边界和增量加载——正是使大型 Angular 应用随时间更容易演化的方式。
TypeScript：提升重构与安全性的意见
让演示更真实
使用自定义域名，提供干净的演示链接以便评审和审批。
Angular 默认使用 TypeScript 并非只是语法偏好——它表达了对大型应用如何演进的意见。当几十人在同一代码库上多年协作时，TypeScript 迫使你描述代码的预期，从而使改动更不容易破坏不相关的功能。
Angular 的 TypeScript 默认强制了什么
默认情况下，Angular 项目会让组件、服务和 API 具有明确的形状。这促使团队：
- 为组件的输入输出添加类型（它们接受/发出什么数据）
- 为服务契约添加类型（方法返回什么、参数含义）
- 为 API 响应和表单值建立一致模型
这种结构让代码库更像一个有清晰边界的应用，而不是一堆零散脚本。
接口、类型与能带来回报的工具链
TypeScript 的真正价值会在编辑器支持中显现：有了类型，IDE 可以提供可靠的自动补全、在运行前发现错误，并完成更安全的重构。
例如在共享模型中重命名字段时，工具可以找到模板、组件和服务中的所有引用——减少那种“搜索然后祈祷”的做法。
在长期改动中减少回归
大型应用不断变化：新需求、API 修订、重组功能和性能工作。类型就像护栏，在这些变动中保护你。当某处不再符合预期契约时，你会在开发或 CI 阶段发现，而不是等到用户走到某个罕见路径时才暴露问题。
不是万能丹，但极大改善团队沟通
类型不能保证逻辑正确、UX 完美或数据校验万无一失。但它们显著提升了团队沟通：代码本身就记录了意图。新成员可以通过类型了解服务返回什么、组件需要什么以及“有效数据”是什么——而无需读完每个实现细节。
Angular CLI：标准化工作流与工具链
先做原型再决定
快速将下一个功能想法变成可运行的应用，然后决定保留哪些约定。
Angular 的意见不仅体现在框架 API 中，也体现在团队如何创建、构建和维护项目上。Angular CLI 是大多数 Angular 应用在不同公司间仍保持一致感的重要原因之一。
CLI 标准化了什么
从第一条命令起，CLI 就设定了共享基线：项目结构、TypeScript 配置和推荐默认值。它还为团队每天要运行的任务提供了一个可预测的接口：
- 项目搭建： 生成一个熟悉的工作区，带推荐的文件夹布局和约定。
- 构建： 一致的生产与开发打包行为。
- 测试： 运行单元测试并查看覆盖率的统一方式。
- Lint/格式化 钩子： 一个强制风格并提前发现问题的通用入口。
这种标准化重要的原因在于构建管道往往是团队分歧并积累“特例”的地方。借助 Angular CLI，很多选择只需一次决策并被广泛共享。
一致的环境与配置
大型团队需要可复现性：同一个应用在每台笔记本和 CI 上应有相似表现。CLI 鼓励把配置集中在一个地方（例如构建选项和环境特定设置），而不是散落的脚本集合。
这种一致性减少了因本地脚本、Node 版本不同或未共享的构建标志造成的难以复现的问题。
代码生成以维持统一模式
Angular CLI 的 schematics 帮助团队以一致样式创建组件、服务、模块等构建块。与其每个人手写样板，不如通过生成引导开发者采用相同的命名、文件布局与链接模式——这类小纪律在代码库增长时带来的回报很大。
如果你想在生命周期更早阶段实现类似的“标准化工作流”效果（尤其用于快速概念验证），有些平台可以从聊天生成可运行应用，然后导出源码并在方向确认后继续以更明确的约定迭代。核心思想是相同的：减少搭建摩擦，让团队把更多时间放在产品决策上而不是脚手架上。
测试约定以支持大型代码库
Angular 带有意见性的测试方案是大团队能在不为每个功能重写流程的情况下保持高质量的原因之一。框架不仅允许测试——还鼓励你采用可重复且可扩展的模式。
Angular 的测试工具包（以及它为何重要）
大多数 Angular 单元与组件测试从 TestBed 开始，它为测试创建一个小型的、可配置的 Angular 运行时，这样测试设置就能镜像真实的依赖注入和模板编译，而不是零散的手工装配。
组件测试通常使用 ComponentFixture，它提供一致的方式来渲染模板、触发变更检测并对 DOM 做断言。
由于 Angular 强依赖 DI，mock 很直接：覆盖 provider 为假实现或间谍对象。像 HttpClientTestingModule（拦截 HTTP 调用）和 RouterTestingModule（模拟导航）这样的通用辅助工具鼓励团队采用相同的测试设置。
来自约定的可重复模式
当框架鼓励相同的模块导入、provider 覆盖和 fixture 流程时，测试代码变得熟悉。新团队成员可以把测试当作文档来读，公用测试工具能在整个应用中重用。
在大型应用中的单元/集成/E2E 测试策略
单元测试最适合纯服务与业务规则：快速、聚焦且易于在每次变更时运行。
集成测试适合“组件 + 模板 + 若干真实依赖”，用来捕捉绑定、表单行为和路由参数等连线问题，而不承担全套端到端测试的成本。
E2E 测试应当更少，保留给关键用户旅程（认证、结账、核心导航），以确保系统整体可用。
实用边界：在哪儿测试什么
把业务逻辑放在服务中并作为重点测试对象。让组件保持轻量：测试它们是否调用了正确的服务方法、响应 @Output() 并正确渲染状态。如果组件测试需要大量 mocking，那通常是信号表明逻辑应该移到服务中。
常见问题
人们说 Angular 是“有意见的”是什么意思？
在 Angular 中，“结构”指框架和工具默认鼓励的一组模式：带模板的组件、依赖注入、路由配置，以及由 CLI 生成的常见项目布局。
“意见”是对这些模式的推荐用法 —— 因此大多数 Angular 应用会以相似的方式组织，这让大型代码库更容易被浏览和维护。
Angular 的这些约定如何帮助大型、长期维护的项目？
它降低了大团队的协同成本。通过一致的约定，开发者不用把时间花在争论文件夹结构、状态边界或工具选择上。
主要的权衡是自由度：如果你的团队更偏好另一套架构，Angular 的默认做法可能会让你感觉受限。
什么是“代码漂移”，Angular 如何减少它？
代码漂移指的是开发者趋向于复制身边已有的实现，随着时间推移引入略微不同的模式。
为限制漂移：
- 标准化功能结构（例如
features/orders/、features/billing/）。 - 使用 CLI 生成器让新代码以相同的形态开始。
- 用 lint/格式化和代码评审清单来强制约定。
Angular 的默认配置让这些习惯更容易被一致采用。
为什么组件是 Angular 可扩展性的核心构建块？
组件提供了统一的 UI 所有权单元：模板（渲染）+ 类（状态/行为）。
它们易于扩展因为边界明确：
@Input()定义组件需要的数据。@Output()定义它发出的事件。- 文件通常是共置的，使功能可发现性更高。
`@Input()` 和 `@Output()` 如何提升大型界面的可预测性？
@Input() 从父组件向子组件传递数据；@Output() 从子组件向父组件发出事件。
这创造了可预测、易于审查的数据流：
- 可以快速看出组件的公共 API。
- 团队可以在不破坏消费者的前提下重构内部实现。
- 屏幕保持可组合，而不是紧耦合。
我应该为功能边界使用 NgModules 还是 standalone 组件？
历史上 NgModule 把相关的组件、指令和服务分组形成功能边界（例如 OrdersModule）。独立组件（standalone）减少了模块样板，但仍通过路由和文件夹结构鼓励清晰的“功能切片”。
实践规则：
- 新的 UI 更倾向于使用独立组件。
- 无论是否使用模块，都要通过路由和目录保持功能边界明确。
如何组织 Core、Shared 与 Feature 代码（并避免“万能 shared 模块”）？
常见划分是：
- Core：应用范围的单例和基础设施（认证、拦截器、全局服务）。
- Shared：可复用的 UI 组件和工具函数。
- Feature：领域特定的代码，不应无限制泄漏到全局。
避免“万能 shared 模块”的方法是保持 shared 轻量、关注单一职责，并按需导入，而不是让每个功能都依赖整个 shared。
为什么 Angular 的依赖注入被视为默认的架构方式？
依赖注入（DI）让依赖关系显式且可替换：
- 更容易测试（用假实现替换真实服务）。
- 更安全的重构（构造函数中的依赖表明类依赖什么）。
- 无复制粘贴的跨切面行为共享。
组件不是 new ApiService()，而是请求服务，Angular 提供合适的实例。
服务应该何时在 root 提供，何时使用 feature 作用域？
提供位置决定生命周期：
providedIn: 'root'实际上是单例——适合跨切面关切，但会在不小心时积累可变状态的风险。- 在功能/路由级别提供可以把状态限制在特定功能或导航上下文中。
要有意图：让有状态服务的归属清晰，避免因为单例机制而产生“神秘全局”状态。
路由、懒加载、守卫和解析器如何支持扩展性？
懒加载提升性能并帮助团队划分边界：
- 用户初次加载更少代码，启动更快。
- 各大功能有各自的路由入口，团队可以在不频繁改动全局 wiring 的情况下演进自己的功能，减少合并冲突和意外耦合。
守卫（guards）和解析器（resolvers）把导航规则写到路由层而不是散落在组件里：前者处理认证/权限/未保存变更等，后者在激活路由前获取必需数据，避免“半渲染”状态。
怎样的路由结构更利于规模化？
一个常见的做法是按功能组织路由：
- 保持一个小且稳定的“外壳”路由配置（例如
/admin,/billing,/settings）。 - 将每个区域懒加载到自己功能模块，并自带路由文件。
- 把功能路由放在功能代码附近，使改动不会波及整个仓库。
这种结构鼓励一致的 URL、清晰的边界和按需加载——正是有助于大型 Angular 应用长期演进的方式。
TypeScript 在 Angular 中带来了什么好处？
TypeScript 的默认使用不仅是语法偏好——它表达了大型应用如何演进的意见。当几十人多年维护同一代码库时，“现在能跑”不够，TypeScript 促使你描述代码的期望，从而使变更更安全。
类型化的输入/输出、服务契约和一致的模型都让代码库更像一个有清晰边界的应用，而不是一堆脚本。
接口和类型化在团队协作中有什么实际价值？
接口和类型加上编辑器支持会带来回报：自动补全、提前发现错误、以及更安全的重构。
例如在共享模型中重命名字段时，工具能在模板、组件和服务中找到所有引用，减少那种“搜索然后祈祷”的做法。
Angular CLI 在大型团队中起到什么作用？
CLI 从第一条命令就设定了共享基线：项目结构、TypeScript 配置和推荐的默认值。它还提供了团队每天要运行的统一接口：
- 项目初始化（熟悉的文件夹布局和约定）。
- 构建（生产/开发的稳定打包行为）。
- 测试（一个运行单元测试并查看覆盖率的方式）。
- Lint/格式化 钩子：在早期捕捉并强制样式。
这些标准化减少了构建管道上分歧导致的“特例”积累。
CLI 如何帮助保持环境和配置的一致？
CLI 鼓励统一配置源（如构建选项和环境设置），而不是大量零散的脚本。这种一致性减少了“在我机器上能跑”的问题——本地脚本、不同 Node 版本或未共享的构建参数引发的难复现 bug。
CLI 的生成器（schematics）还能把组件、服务、模块以一致风格快速创建出来，避免每个人手写样板代码带来的差异。
Angular 的测试模式为什么适合大型代码库？
Angular 的测试故事带有意见性，这让大团队在不重写流程的情况下维持高质量。
大多数单元和组件测试以 TestBed 开始，它为测试创建一个小型可配置的 Angular “迷你应用”，用来模拟真实的依赖注入和模板编译。
组件测试常用 ComponentFixture，提供一致的方式渲染模板、触发变更检测并在 DOM 上断言。通过覆盖 provider 可以轻松做 mocking；常用模块如 HttpClientTestingModule 和 RouterTestingModule 也使测试设置更统一。
在大型应用中，应如何划分单元/集成/端到端测试？
当框架鼓励相同的模块导入、provider 覆盖和 fixture 流程时，测试代码会变得熟悉。新人把测试当成文档来读，公用测试工具（构建器、常用 mock）能跨越整个应用重用。
单元测试适合纯服务和业务规则；集成测试适合“组件+模板+一些真实依赖”；E2E 测试应当有限，仅覆盖关键用户流程（认证、结账、核心导航）。
表单和 HTTP 的哪些模式能提升一致性？
Angular 在表单和网络请求方面的约定尤其明显：当团队统一使用内置模式时，代码评审更快、问题更易复现、新功能不会重复造相同的管道。
表单方面：支持模板驱动和响应式两种方式。模板驱动对简单表单适合；响应式表单（FormControl/FormGroup）在复杂、动态或校验密集的场景下更易扩展。团队通常会标准化一个“表单字段”组件来统一标签、提示和错误信息的渲染。
HTTP 方面：HttpClient 使用可观察流和类型化响应，拦截器（interceptors）允许在单处处理跨切面行为：添加认证头、刷新 token、记录请求时长、规范化错误、统一重试或用户友好消息等。把这些逻辑集中到拦截器比在每个服务里散布处理要好得多。
在规模化场景下，如何保持性能可预测？
性能与可预测性紧密相关：Angular 倾向于让你思考“什么时候”和“为什么”更新视图，而不是随意在任何地方更新。
变更检测的关键心智模型是：更新应当是有意且局部化的。组件树中越少不必要的检测，随着界面密度的增加性能就越稳定。
Angular 的惯用做法包括：
- 默认对展示组件使用
ChangeDetectionStrategy.OnPush。 - 列表使用
trackBy避免不必要的 DOM 重建。 - 使用懒加载路由来减小初始包体积。
把这些作为团队约定能防止在新增功能时意外退化性能。
有哪些权衡或情况下 Angular 的约定可能不合适？
权衡是不可避免的：
- 学习曲线：依赖注入、RxJS 模式和模板语法需要时间消化，尤其来自更简单栈的团队。
- 冗长性：Angular 倾向显式配置和清晰边界，意味着小功能可能需要更多文件和“仪式”。
- 灵活性减少：约定和“Angular 方式”会限制尝试新方法，你仍然能集成其他工具，但经常需要把它们适配到 Angular 的模式上。
如果是原型、营销页或短生命周期的内部工具，开销可能超过好处；小团队有时更喜欢无约束的框架以便快速试错。
有哪些决策标准或渐进式采用策略？
一些实用问题可以帮你决策：
- 团队规模与流动性：新开发者会频繁加入并需要快速上手吗？
- 生命周期：这是多年的产品还是一次性的项目？
- 复杂度：会有大量功能、路由、用户角色和集成吗？
- 合规需求：是否需要一致的测试、审计和可预测的发布流程？
渐进式采用也是可行的：先收紧约定（lint、文件结构、测试基线），然后逐步引入独立组件和更清晰的功能边界。迁移时优先稳定改进而不是一次性大重写，并把本地约定写成文档来教导新人。