Headless commerce 常被包装成一次升级：更灵活、更快、设计自由。有些时候确实如此。但 headless 是工具，不是勋章，在 Shopify 上它有一笔实打实的税——丢失的特性、更高的维护成本、以及一个从此由你的团队端到端负责的前端。这篇文章是反方向的决策框架：什么时候主题（theme）仍是正确架构，以及如何在花掉六个月和六位数预算之前判断清楚。
为什么默认应该是主题
Online Store 2.0 的主题架构（Liquid + JSON 模板 + sections）免费给你：原生特性——checkout 扩展、Shop Pay、市场与语言切换、自动折扣、客户账户、整个应用生态，在 headless 方案里每一样都要重建；商家已熟悉的编辑器——headless 意味着你的团队要自己构建并长期维护替代品；足够高的性能上限——纪律良好的主题可以达到 Core Web Vitals 目标，当瓶颈是应用和图片（两种架构里是同一个问题）时，headless 的优势很边缘。
这不等同于“永远不要 headless”，而是举证责任在 headless 提案那一侧，不在主题这一侧。
决策框架
五个问题，多数答不上来就停下来重新想：
- 真正的约束是什么？ 精确写下主题做不到的事。“想要自定义商品页”不是约束，主题做得到；“一个店铺要三套 checkout”才是。渲染环境（原生 App、自助终端、第三方界面）才是 headless 的地盘。
- 明天谁拥有这个前端？ 一个还要管营销的小型内部团队，主题赢。Headless 前端是真正的软件——构建流水线、部署、测试、依赖升级、安全补丁，成本是永久条目。
- 编辑体验需要是什么样？ 商家每周改页面，主题编辑器本身就是特性。任何 headless CMS 都要先做内容建模和编辑工作流两个项目，才轮到编辑。
- 路线图上有哪些 Shopify 特性？ Shopify Functions、Markets、B2B on Shopify、Subscriptions——要么主题原生，要么需要自定义管道，逐项对照这些特性的 headless 成熟度。
- 真实的性能差距是多少？ 先测量再架构：LCP 时间花在哪？被应用和图片吃掉的话，修它们比换架构便宜；主题本身确实无法优化（很少见）时 headless 才有理由。
一个强答案（渲染环境、主题碰不到的路线图特性）足以支撑迁移；三个弱答案（“更多设计自由”“听说更快”“大家都在做”）是穿着 headless 外衣的主题决策。
Headless 提案藏起来的成本
特性滞后： Shopify 发布主题特性时，你的前端等团队移植；发布 API 变更时，集成断在你修复之前。Checkout 复杂度： headless 下不能完全自定义 checkout，只能扩展，先对照 Checkout Extensibility 的真实表面再承诺。应用生态摩擦： 多数应用为主题构建，要么接受局限，要么自己写集成。编辑器税： 面向商家的编辑体验是一个有需求、QA 和支持的产品，而且是为每一种页面类型。
折中方案：在值得的地方 headless
最强架构常是混合的：目录与 checkout 关键流程用主题，真正值得的地方——原生 App、活动体验、自定义配置器——用 headless。Storefront API 与 Hydrogen 让一个后端、两个渲染器、共享购物车保持连贯。把 headless 当作按界面选择的技术选项，而不是现代店铺的必然归宿。
什么时候需要外部帮助
如果你正被要求论证一份 headless 提案，或被迫去建一个而直觉认为约束不成立，一次有边界的商务架构评审可以把决策对着路线图、团队和真实性能数据压力测试。如果答案是“主题”，那也是好结果：预算省下来留给推动营收的工作。带着这五个问题来预约 Commerce Architecture Review。