① 困境锚定
做小程序第一个项目的时候，我犯了一个"看起来很合理"的错误：每新增一个功能，就建一个云函数。
用户登录？建一个。上传文件？建一个。查列表？再建一个。审核？再来一个。
做到第15个云函数的时候，微信开发者工具的云函数面板已经滚不动了。每次本地调试要先上传，上传完等冷启动，冷启动完了发现传错了一个参数——再来一遍。
更要命的是线上环境。用户请求一个页面，后端要调5个不同的云函数，5次冷启动串起来，首屏加载直接慢到怀疑人生。
那一刻我才意识到：不是功能写得不对，是架构从一开始就歪了。
② 误区打脸
很多刚接触云开发的人都会掉进同一个坑：一个云函数处理一个任务。
这看起来很"云原生"、很"微服务"。腾讯云官方教程也是这么教的——每个示例都是"创建一个云函数，写一个exports.main"。
但现实是：
小程序云函数有冷启动成本。每个云函数第一次被调用时，需要初始化运行环境、加载依赖包。当你有20个云函数、每个平均依赖5个npm包时，用户的每一次操作可能都在为冷启动买单。
而且云函数数量一多，联调成本指数级上升。前端每调一个接口要传不同的函数名，后端每改一个逻辑要找到对应的云函数目录重新上传。等你加了权限校验——恭喜，20个云函数里每个都要复制粘贴一遍鉴权代码。
这就好比你开了一家餐厅，每道菜单开一个厨房。厨房多到厨师在厨房之间跑的时间比炒菜还长。
③ 思维框架
后来我接触了一个思路：能不能用一个云函数，搞定所有事情？
答案是可以的。核心工具是一个叫 tcb-router 的库，它的原理不复杂——你在云函数内部做一层路由分发，前端调用时传入一个路由标识，云函数根据标识分发给对应的处理函数。
就像餐厅只有一个厨房，但里面有负责炒菜的、负责凉菜的、负责甜点的——进来一个菜单，厨房内部自己分工。
但光有路由还不够。当你所有接口都塞进一个云函数时，权限问题就来了：登录接口任何人都能调，审核接口只有管理员能调，普通查询需要登录用户。
这时候就需要中间件。在路由分发之前加一层"安检"：请求进来先过权限校验，不合规的直接拦截，合规的放行给对应的业务处理器。
这个思路捋下来，架构就清晰了：
请求 → 中间件（日志记录 + 权限校验）→ 路由分发 → 业务处理 → 响应
一条线，很干净。不用在每个业务函数里重复写鉴权逻辑，不用维护几十个云函数目录，调试时只需要盯一个入口。
④ 实战一瞥
拿登录流程来举例。
用户打开小程序，前端拿到微信的openid，调用云函数，路由标识是 user/login。
请求先进日志中间件——记录谁在什么时间调了什么接口、传了什么参数、花了多长时间。这个中间件不阻塞业务，记录完了就放行。
然后到权限校验——登录接口不需要任何角色，直接放行。但如果请求的是 review/action（审核操作），权限中间件会查数据库，看这个用户是不是管理员。不是的话直接返回"权限不足"，业务代码一行都不会执行。
最后到业务处理器——查询用户是否存在，不存在就创建新记录，存在就更新信息，返回结果。
整个过程，前端只调了一个云函数名，只传了一个路由标识。对前端来说，跟调一个普通接口没有任何区别。
这个架构做到后期，我加了十几个新功能，云函数数量始终是1个。新增功能只需要加一个路由和处理函数，权限控制只需要在路由注册时指定中间件级别。
⑤ 留白引导
架构选型的核心不在于用什么工具，而在于你能不能在动手写第一行代码之前，想清楚数据怎么流、权限怎么管、后期怎么扩展。
tcb-router 的路由注册方式、中间件的写法、权限粒度的划分——这些细节每一个都有几种不同的实现路径，选哪条取决于你的业务场景。
篇幅有限，完整的架构搭建过程和中间件实现细节没法一次性展开。如果你也在做小程序云开发的项目，或者正在为云函数数量爆炸发愁，可以聊聊你的场景，我来帮你看看怎么规划最合适。
