一个卖10件T恤的独立站，需要配齐数据库、后台系统、CMS订阅、后端服务——这套组合拳打下来，月成本轻松破百刀。前端工程师Nico搞了个实验：如果把这些全砍掉，能走多远？
他交出的答卷叫AURORA Commerce。没有数据库查询，没有API调用，产品数据存在YAML文件里，支付走Stripe，部署后基础设施成本归零。这不是概念验证，是已经跑通的Nuxt 4（一种Vue.js全栈框架） storefront。
把商品目录当成代码仓库管
传统电商的数据流像外卖厨房：前台接单→对讲机喊给后厨→厨师翻纸质菜单找配方→现做。Nico的做法是直接让前台抽屉里躺着所有配方卡片，要哪张抽哪张。
他的产品目录长这样：
content/products/heavyweight-crewneck-charcoal.yml 文件里，一件卫衣的全部信息——ID、英法双语标题、价格、面料克重、尺码表、甚至用户评价——以纯文本形式躺死在那里。
改价格？改个数字。上新？复制粘贴改文件名。部署？git push完事。没有后台登录界面，没有数据库迁移脚本，没有API密钥轮换焦虑。
听起来像开倒车。但Nico算过账： curated catalog（精选目录）模式下，SKU常年稳定在10-50个，用重型武器打蚊子才是真的浪费。
Nuxt Content v3（Nuxt的内容管理模块）负责把YAML翻译成类型安全的查询接口。取全站商品：
const { data: products } = await useAsyncData('products', () => queryCollection('products').where('active', '=', true).order('productId', 'ASC').all())
按slug取单件商品同理。代码里的查询语法和SQL神似，但跑在构建时和客户端，不碰数据库。
Stripe成了唯一的"外部依赖"
支付环节没法省，也没必要省。Stripe的Checkout Session托管支付流程，Nico只需要在服务器端（Nuxt的server路由）创建会话、监听webhook更新订单状态。
订单数据存在哪？JSON文件。同样丢进git仓库，同样版本可控，同样零成本。这个设计有显然的天花板——并发写入会冲突——但对于日均几十单的体量，文件锁都懒得触发。
整套架构的硬性约束写在脸上：只服务"小而美"的精选电商，SKU过百就开始别扭，过千就是自虐。
Nico的原话是："It sounds almost too simple. It kind of is — and that's the point."（听起来简单得过分。确实简单——而这正是重点。）
谁该抄这个作业
三类人看了会心动：设计师品牌主理人，产品少但迭代快，讨厌Shopify的模板束缚；技术型创业者，想把每一分钱砸在获客而非服务器；以及所有被"必须上微服务"的噪音烦透的前端工程师。
代价也明码标价。没有实时库存扣减，没有多仓库逻辑，没有复杂的促销规则。YAML写错一个缩进，线上直接报错——这既是bug也是feature，逼你用代码审查代替人工审核。
Git历史成了天然的内容审计日志。谁改了价格、什么时候上的新、哪次把"Charcoal"拼成了"Charcol"，blame命令一查便知。对比传统后台的"操作记录"模块，这反而更透明。
部署策略是另一个隐藏福利。Vercel/Netlify的免费档足够扛起静态生成+边缘函数，全球CDN默认自带。Nico没提具体数字，但同类项目的经验值是：月流量10万PV以内，账单显示$0。
技术选型上，Nuxt 4的稳定性、Nuxt Content v3的类型安全、Stripe的支付合规，三者拼成最小可行三角。换掉任何一角，复杂度都会指数级膨胀。
这个实验最狠的启示或许是：我们默认的"技术债"，很多是"技术奢侈"。数据库不是必需品，是舒适区。后台系统不是刚需，是路径依赖。当业务规模够小、变动够频繁、人员够精简，做减法比做加法更需要勇气。
一位叫Théo G.的顾客在YAML里留下了评价："The weight is perfect and the finish feels way above standard sweatshirts."（克重恰到好处，做工远超普通卫衣。）这条五星好评躺在代码仓库第47行，和面料参数、尺码表、多语言文案挤在一起——没有数据库表关联，没有JOIN查询，就是纯文本。
如果明天你的独立站只剩20个SKU，你会选择继续供养那套后台系统，还是把商品详情直接写进代码？
热门跟贴