北京
“显式代码比隐藏魔法更容易推理。”Wasp 团队一直把这句话当作框架设计的座右铭。当 Next.js 这类全栈框架靠着“把文件夹变成路由”的约定式魔法大杀四方时，Wasp 却反其道而行，坚持让开发者在 main.wasp.ts 文件里逐条声明路由。这种像是“反主流”的固执，在最新一次更新中终于出现了松动——团队想通了一件事：魔法可以存在，但咒语得由你来编。
时间拉回几年前，文件路由几乎成了现代 Web 框架的出厂标配。你创建一个 about-us/page.tsx，应用就自动对接到 /about-us；改一下文件名，URL 也跟着变。这套读文件夹的神通固然省事，副作用也很明显：想给某个文件夹赋予特殊含义，或者在同一个路由下面根据登录状态分别展示不同页面，基本只能靠提需求然后等框架厂商施舍。Wasp 对这些“潜规则”一直心存警惕，所以迟迟没有把文件路由塞进框架。
Wasp 是一个主打“电池全装”的 TypeScript 全栈框架，试图把前端、后端和数据库揉成一个整体。它的核心哲学叫“显式 Spec”：应用的路线、认证、查询、定时任务等等功能，全部明明白白写在代码里，而不是藏在某个目录结构后面。框架拿到这份 Spec 之后，再把这些零碎的声明编译、缝合，变成真正跑起来的应用。团队认为，透明结构对团队协作和 AI 代码助手都更友好——机器更容易读懂一张清晰的功能地图。
转折来自 main.wasp.ts 文件的一次性质变化。它不再是一份让框架被动读取的静态 JSON，而是一个标准的 Node.js 程序，用 TypeScript 编写。这意味着你可以在里面写任意逻辑，包括自己去遍历文件树、匹配命名规则，再用 50 行左右的代码搭出一个完全符合项目需求的文件路由系统。换言之，框架把创造“魔法”的权限交还给了开发者，而不是继续用一套写死的约定把所有人框住。你不用再等待框架团队批准某个文件夹格式，也不想再看到路径命名的“意外惊喜”。
这步棋背后是 Wasp 对显式原则的一次重新校准：“显式”不是要把所有自动化拒之门外，而是要确保自动化过程本身也是可阅读、可掌控的代码，而不是一个黑盒。新的文件路由能力本质上只是 Spec 文件编程能力的一个应用示例，但它精准击中了开发者长期以来的痛点：既想要文件路由的省事，又不想被框架的“魔法”限制住手脚。50 行代码，就是一个程序员找回控制权的最小成本。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
