过去一年我们交付的二十多个系统开发项目里，有近三成在中期评审时暴露出架构层面的隐患。这些隐患往往不是技术选型本身对错，而是团队在决策时掉进了几个反复出现的认知陷阱。

误区一：把"流行"当成"合适"

微服务、Serverless、中台化——这些词在技术社区的热度很容易左右选型判断。一个日订单量不足两千的本地零售客户，曾被建议拆成七个微服务，结果光是服务间通信和链路追踪的运维成本就吞掉了大半预算。

架构选型的核心依据应该是业务量级、团队规模和迭代节奏，而不是技术趋势。我们在给客户做商务技术咨询时，通常会先量化三个指标：峰值并发、数据增长速度、发布频率，再倒推架构方案。

常见误判对比

• 单体架构：适合团队5人以下、业务边界尚不清晰的早期阶段，部署简单，调试链路短
• 微服务架构：需要成熟的CI/CD、日志聚合、服务治理配套，否则分布式事务会成为噩梦
• Serverless：冷启动延迟对实时性要求高的小程序制作场景并不友好，需谨慎评估

另一类高频问题是数据库选型跟风。看到别人用MongoDB就放弃关系型数据库，却没考虑自身业务存在大量多表关联查询。等到数据运维阶段发现一致性难以保障，迁移成本已经很高了。

优化建议：从可演进性出发

比较务实的做法是采用"模块化单体"起步，在代码层面划清领域边界，为未来拆分预留接口。这样既控制了初期复杂度，又不会把路堵死。

同时建议把数字化服务的可观测性建设提前到架构设计阶段——日志、指标、链路追踪三件套的接入成本，越晚做越高。我们内部的经验是，每延迟一个迭代周期补埋点，工作量大约增加40%。

架构没有标准答案，只有与当前阶段匹配度最高的解。定期回顾、小步调整，比一次性设计一个"完美架构"更现实。