工程化仓库与微前端的协作边界前端工程化的价值是让依赖、构建和发布有可复现的规则而不是在仓库里累积更多配置文件。Monorepo 与微前端解决的问题不同前者主要管理共享代码和工作区关系后者主要解决多个独立应用如何共存。两者可以一起用但不应互相替代。从依赖方向划分工作区一个工作区通常包含应用、共享组件、业务领域包和构建配置。包的入口必须稳定其他包只能从公开入口引用不能通过相对路径穿透到内部文件。这样重构内部目录时不会意外影响多个应用。组件包也应把运行时依赖、开发依赖和 peer 依赖分清否则宿主应用可能加载到两份框架运行时。packages: - apps/* - packages/*目录声明只是开始。还需要为每个包配置类型检查、测试和构建入口持续集成根据受影响的依赖图挑选任务。公共设计 token、lint 规则和构建工具可以共享但业务逻辑不宜为了“复用”被强行抽成万能包依赖方向越清楚排错越简单。微前端先约定宿主职责宿主应负责路由入口、登录态边界、错误兜底和全局样式策略子应用负责自身页面和可版本化的对外契约。通信使用明确的事件或接口不让子应用随意读取宿主内部 store。样式隔离要考虑弹层、字体和重置样式单靠命名约定难以避免冲突。加载失败也是契约的一部分。某个子应用不可用时宿主需要显示哪种降级界面是否允许用户继续访问其他功能错误信息由谁收集都应在实现前说清。把远程地址和版本策略散落在业务代码里会让发布排查变得困难应该集中配置并提供回退路径。发布过程保持可追踪共享包升级时先确认哪些应用依赖它再在兼容范围内发布。对破坏性改动写清迁移方式不用“最新版即可”的口头约定代替版本约束。构建产物的来源、环境变量和变更记录也要保留出现问题才能定位是代码差异、依赖解析还是发布配置导致。在干净环境里验证验证从全新安装开始依次执行类型检查、受影响包测试和生产构建。再用宿主加载不同版本的子应用检查路由跳转、样式、鉴权过期和加载失败。这里不需要虚构压测数字只要把实际运行的命令、依赖版本与发现的问题记录下来工程规则就能持续被校验。对无法在本地完整复现的集成环境也要明确依赖哪些服务和配置避免把环境差异误判为代码问题。补上容易遗漏的一段阅读这类方案时最值得回看的不是顺利完成的那次而是条件改变后的行为。围绕“从依赖方向划分工作区”可以故意换掉一个前提缺少必要字段、服务返回慢、配置与预期不同或者任务被中途取消。观察“微前端先约定宿主职责”会怎样接住这个变化再检查“发布过程保持可追踪”有没有留下误导性的成功状态。这样得到的是处理规则不是一段漂亮的结论。文档里可以保留一张很短的操作说明触发条件写成可识别的输入输出写明保存位置或可见现象失败时写出停止点和恢复方式。它不用替代正式文档却能帮助后来的人复走“从依赖方向划分工作区”这条路径。涉及配置时把版本、开关和依赖条件放在同一处涉及异步处理时明确谁负责查看结束状态。如果这部分会被交给同事维护验收不要只问“有没有完成”。更有用的问题是看着“微前端先约定宿主职责”的结果能否判断输入是否被正确消费修改“发布过程保持可追踪”后能否找到受影响的地方撤掉这次改动时是否会留下半成品。答案不必承诺绝对安全但应当能对应到代码、配置或现有记录。视觉效果、交互回退和资源释放不能由约定俗成来保证。本文的内容可以先从一个小场景开始使用碰到与假设不符的输入再把新发现补回规则而不是为了整齐把差异抹掉。