Composing 是面向 Umbraco 17+ 的代码注册实践说明，讲解如何把自定义代码在站点启动时接入框架。
用途与定位 注册可以放在两个受支持的位置，二者调用同一个 IUmbracoBuilder 扩展方法，因此之后在两者之间切换只会改变调用来源。 A — Composer（默认） B — Program.cs
两种方式对比 查找方式：A 通过类型扫描 IComposer，在 .AddComposers() 内运行；B 在 CreateUmbracoBuilder() 链中显式调用。 执行时机：A 在多个 Composer 之间按未指定顺序运行，除非使用 [ComposeAfter]/[ComposeBefore]；B 在所有 Composer 之后运行（放在 .AddComposers() 之后）。 类库/包/RCL 可用性：A 可用，且这是唯一选项；B 不可用，因为包无法修改宿主的 Program.cs。 最佳适用：A 适合自包含功能、包、多项目解决方案；B 适合需要覆盖某个 Composer（包括第三方包）所注册内容的站点代码。
编码前提示 写任何代码前，先打开所选方案的参考文档并从其资产开始；Umbraco 17 的陷阱只在那里覆盖。例如 ContentFinderByUrl 仍能编译但不再被注册，锚定它会启动失败；AddUnique 会悄然把作用域服务变成单例。
如何选择 默认选 A。当用户拥有 Program.cs，且需要某个注册胜过无法编辑的 Composer 所做注册，或明确希望所有注册都可见于 Program.cs 时，选 B。若有歧义，推荐 A 并用一行提及 B。
共享主题 两种方案共享两个主题，按任务涉及内容阅读： collections-and-ordering.md：向 Umbraco 集合添加、插入、替换或移除项，替换单个服务，Composer 顺序，以及禁用某个 Composer。 startup-and-runtime-levels.md：在 Umbraco 启动或停止时运行的代码（组件或通知处理器），以及按运行时级别进行门控。
版本兼容性 目标为 Umbraco 17+。IComponent（同步 Initialize/Terminate）在 17 中已过时，并计划在 18 中移除，应改用 IAsyncComponent 或其某个基类。
最佳实践 每个功能一个 Add<Feature>() 扩展，且只从一处调用。同时从 Composer 和 Program.cs 调用并非无害：集合会去重，但服务注册和异步通知处理器不会去重，会被注册两次，处理器也会触发两次。 Compose() 只做注册。此时运行时级别尚不可知，且 Composer 在每个级别（安装、升级、启动失败）都会运行；因此在 Compose() 内不要解析服务、调用 BuildServiceProvider()、访问数据库或做 I/O。启动工作应放在组件或启动通知处理器中。
验证 客观断言位于 evals/evals.json，用 umbraco-skill-evaluator 运行。方案 A 为 Asserted：其资产由 dotnet test 门禁编译并断言（examples/approach-a-composer/）。方案 B 为 Compiled：examples/approach-b-program-cs/ 会构建其资产以及 .AddComposers() 之后的 Program.cs 接线，但没有宿主运行它，因为共享参考宿主有自己的 Program.cs。评估会评分放置位置。