第二章 · 菜单不是清单，是 API

门店的墙刷好了，桌椅摆上了，龙餐馆开张前要拍板的第一件事，不是招人，也不是买锅——是定菜单（一张纸，上面写着「你能点什么、每样多少钱」）。

大多数人把菜单当成一份清单：把老板会做的菜一道道列出来，越长越显得本事大。但如果你写过一天代码，你会在这张纸上认出一个老朋友。菜单不是清单，是接口。

菜单是龙餐馆对外的一纸契约

先说清楚API（也叫接口，Application Programming Interface）是什么。它是一个系统对外公开的「你可以这样调用我」的约定：你按规矩把请求递进去，我保证按规矩把结果吐出来。你不需要知道我内部怎么实现的，你只需要相信这个约定。

说人话：接口就是一张点菜单。你不用会做鱼香肉丝，也不用进后厨，你只要说出「鱼香肉丝」这五个字，二十分钟后它就该端到你面前，而且和上次那盘味道差不多。你和后厨之间那条看不见的约定，就是接口。

菜单一旦印出来挂在墙上，龙餐馆就对外做了两个硬承诺：

点了就得能出。菜单上有的，客人有权点。你不能让客人念完一整页，才在每一道后面听到「这个今天没有」。一张全是「售罄」的菜单，等于一个天天报错的接口——没人会再信它。
味道得稳定。同一道菜，今天和上周得是同一个东西。接口最值钱的品质不是花哨，是可预期：我调用它一百次，得到一百次一样的结果。餐馆里这个词叫「出品稳定」，说的是同一件事。

这就是为什么好餐馆宁可把一道菜从菜单上撤掉，也不愿意「凑合出一盘」。撤菜是诚实地缩小接口，凑合是偷偷违约。工程师对后者的容忍度，应该和对餐馆的一样低。

客人看菜单，看到的是「宫保鸡丁 38 元」。后厨看这一行字，看到的是一串被折叠起来的东西：

「38 元」只是这次调用的价格标签，真正的成本藏在这三样看不见的依赖里。菜单上那一行短短的字，本质是一次函数调用的签名：写着名字和价格（输入输出），把实现细节全藏在后厨（这些细节怎么跑，是第三章的事，这章先按下不表）。

这里是最容易被忽略、也最要命的一点：菜单上几十道菜，看起来各点各的、互不相干，其实它们共享同一批底层资源。

同一把葱姜，切给这道也切给那道；同一口炒锅，炒完鱼香肉丝接着炒宫保鸡丁；同一个厨师，两只手在十道单子之间来回切。这就像一堆不同的接口，背后连着同一个数据库、同一个连接池。表面上你在调用十个不同的功能，底层它们都在抢那几样有限的东西。

说人话：菜单越长，不是「后厨的活变多了」这么简单，而是「同样一口锅、同样一双手，要被切成更多份去伺候更多种菜」。资源没变多，抢它的人变多了。

新老板最常犯的错，是觉得菜单越长生意越好——川菜粤菜火锅烧烤全都来，总有一道戳中客人。听起来是「丰富」，实际上你踩进了一个叫组合爆炸的坑（选项一多，它们互相搭配出的情况数量会像滚雪球一样暴涨，远远超过你的直觉）。

先认识另一个词。SKU（库存量单位，Stock Keeping Unit）是「需要被单独管理的一个品种」。对后厨来说，多一道用到新食材的菜，往往就意味着多好几个 SKU：这道菜要单独进一种货、单独腾一格冰箱、单独备一份料、单独占厨师脑子里一条「怎么做」的记忆。

菜从 20 道加到 40 道，账面上只翻了一倍。但背后的负担远不止一倍：

这和软件里「接口越多越难维护」是一模一样的病。每多一个对外承诺，你就多一处要测试、要兼容、要在半夜出问题时爬起来修的地方。菜单不是越长越强，是越长越脆。

反过来看那些只卖几样东西的店：一碗牛肉面、一只烤鸭、一份炸鸡。它们的菜单短得可怜，可后厨往往快得惊人、稳得吓人。

原因不神秘。菜少，用到的食材种类就少，同一批葱姜、同一锅高汤能被反复复用，备料能备得又深又足；动作少，厨师把那几样练成了肌肉记忆，闭着眼都不会错；要盯的 SKU 少，库存清爽、损耗低、出错面小。

说人话：一个收敛的、只做几件事的接口，比一个什么都想接的接口好维护得多。餐馆和代码在这件事上完全同构——把接口做窄，是在给未来的自己省命。

那是不是菜越少越好？也不是。只卖一样东西，等于把整家店押在一个接口上：这道菜过气了、这拨客人吃腻了，你连个备选都没有。这是另一种极端的脆。

所以定菜单，本质是在两股力之间找平衡：

成熟餐馆的经验，往往是「窄核心 + 少量变体」：拿几样共享同一批底层食材和工位的招牌菜撑起后厨的效率，再用几道边角菜去覆盖不同口味——关键是这些边角菜尽量复用已有的食材和动作，而不是每一道都拉进一整套新的 SKU。这和软件里「稳定的核心接口 + 克制的扩展」是同一种审美。

所以，龙餐馆开张前的第一张纸，看着是给客人挑菜用的清单，其实是我们对外立下的一整套契约，也是压在后厨肩上的一整套账。菜单定完了，接口挂出去了——可客人一开口，后厨那口锅、那双手、那条从生到熟的路，到底是怎么把这一行字变成一盘热菜端出来的?这条流水线，是下一章的事。