本地开发一切正常，构建流程顺利通过，OpenNext甚至正确列出了所有博客路由。但部署到Cloudflare Workers后，打开博客页面——一片空白。

问题不在MDX解析，不在frontmatter格式，也不在路由配置。真正的症结是：代码还在用Node.js的思维模式，而Cloudflare Workers运行的是打包后的Worker产物。

打开网易新闻 查看精彩图片

具体来说，开发时用的是node:fs在请求时读取博客文件。这在本地没问题，因为源文件就在磁盘上。但OpenNext构建完成后，应用跑在Worker bundle里。虽然Cloudflare通过虚拟文件系统支持node:fs，但这个文件系统≠生产环境挂载的项目文件夹。bundle内的文件可读路径是/bundle，/tmp则是请求级别的临时空间。

解决方案是把博客发现移到构建阶段。写一个预构建脚本，读取.mdx文件、解析frontmatter，然后生成TypeScript文件供应用正常导入。作者继续用文件方式写博客，但运行时Worker不再需要扫描content/blog文件夹。

具体做法分三步：构建前运行脚本生成元数据和静态导入文件；构建时将MDX组件打包进bundle；运行时直接导入生成的模块渲染对应内容。这样保留了基于文件的写作体验，同时消除了运行时的文件系统依赖。