在Web开发的演进历程中，组件化与微前端如同两股潮涌，先后席卷了前端工程化的滩涂。组件化以Vue、React等框架的普及为标志，将界面拆解为可复用的独立单元，试图通过粒度的控制来对抗复杂性的熵增。微前端则顺应了大型组织多团队协作的需求，允许不同的技术栈、独立部署、自治的团队在同一个超级应用中共生。然而，当我们剥离脚手架与工具链的喧哗，会发现这两者并非对立的路线，而是同一场关于“边界”的战争在不同维度上的投影。真正值得追问的不是组件化好还是微前端好，而是我们为什么需要边界，以及边界应该划在哪里。
组件化的胜利表面上唾手可得，但代价被长期掩盖。它确实降低了UI的重构成本，让设计系统得以落地，也让团队按模块分工成为可能。然而，组件化只解决了界面碎片的拼接，却未真正触及逻辑与状态的复用。我们依然能看到数百个被反复复制的useEffect，看到散落各处的API请求逻辑，看到props层层透传的畸形肥胖组件。这些现象揭示出：当边界只画在渲染层，而数据流、业务规则、交互行为被强制塞进同一个黑盒时，复用的承诺就沦为一种幻觉。组件化最大的失误，不是它的存在，而是它被误认为解决一切问题的银弹，导致人们将架构级的设计压力转嫁给了标签结构。
微前端则在另一边扮演了纠偏者。它将边界提高到了应用层，使每个业务域都成为拥有完整生命周期的独立部队。这种思路聪明地映射了康威定律：既然组织是分权的，那么架构就必须是可断裂的。微前端的真正价值在于它强制划分了归属权——技术选型的归属、发布节奏的归属、甚至是失败责任的归属。但与此同时，微前端让团队付出了沉重的成本：共享依赖的重复加载，全局事件的相互踩踏，以及那条永远难以根治的样式隔离沟壑。更重要的是，微前端并没有带来真正的隔离，它只是把边界从代码文件挪到了运行时，让“集成”变成了更隐蔽的挑战。当我们用iframe隔离样式，用自定义事件通信，用妥协的方式处理路由冲突时，边界反而成了系统中最脆弱的焊点。
如果我们将组件化和微前端放在同一张时间轴上看，会发现它们的核心问题都是：边界应画多粗、画在哪里、谁来维护。组件化追求细粒度，带来了灵活，却丧失了全局一致性；微前端追求粗粒度，带来了主权，却牺牲了跨域的协同效率。新的独立观点是：我们不应继续在粒度的单轴上左右摇摆，而应建立分层边界架构——将边界视为一个可组合的连续谱，在不同层级上使用不同的约束模型。在组件层，让我们用Headless UI和自定义Hook来封装行为与状态，而不是封装DOM；在模块层，用模块联邦来动态加载与组合，而不是静态打包；在应用层，用微前端来处理安全边界与团队自治。这种分层边界不试图找出唯一正确的切分方式，而是允许系统在同一时刻拥有多种粒度的边界，并让它们通过契约（例如Zod schema、状态机描述）来通信。
这场关于边界的战争永远不会结束，因为每一次架构升级都只是将复杂性推向了另一个维度的边界。但当我们放下“组件化必死”或“微前端无用”的二元对立，转而将两者看作可组合的架构要素时，我们会获得一种新的元视野：最重要的不是边界本身，而是定义边界的能力。未来Web开发的竞争力，不再取决于使用哪个框架或哪种部署模式，而取决于我们能否像雕刻家一样，在混沌中精准地刻出那条既不过深也不过浅的缝。那才是真正的架构智慧——知道在何处落刀，比刀本身更珍贵。
