能否在SvelteKit项目中包含后端API、敏感数据与CPU密集型代码？

SvelteKit 官方原生支持同仓库全栈开发，不存在任何框架层面的限制，也没有官方指引要求必须拆分独立后端服务。这种单体模式对个人开发者、小团队来说开发效率极高，是非常主流的用法，你只要解决了托管平台的CPU限制问题，完全可以这么用。

什么情况下才不建议用这种单体模式？ #

只有几个特定场景会产生额外成本，不存在通用的“不推荐”理由：

• 前后端团队完全独立、技术栈选型差异极大，代码放在同一个仓库会互相掣肘
• 你需要跑的CPU密集型任务是小时级的长任务（比如批量视频转码、TB级数据清洗），这类任务本身就不适合和Web服务绑在同一个进程里，就算拆独立API服务也得单独搭任务队列，和SvelteKit本身没有关系
• 你要对外提供大规模开放API、需要做复杂的多租户限流、多版本并行管控，这时候拆分独立网关/API服务扩展性更好，但日活十万以内的项目直接用SvelteKit端点完全能扛

1. 安全的服务端代码目录结构 #

SvelteKit 本身自带服务端代码隔离机制，只要遵循框架约定，根本不会出现服务端代码泄露到客户端的问题，推荐结构如下：

src/
├── hooks.server.ts       # 全局服务端钩子：鉴权、请求日志、跨域处理等
├── lib/
│   ├── server/           # *核心隔离区* 所有敏感服务端逻辑必须放这里
│   │   ├── db.ts         # 数据库连接实例、查询封装
│   │   ├── auth.ts       # 密码校验、签名生成、权限判断逻辑
│   │   ├── tasks/        # CPU密集型任务逻辑：图片处理、数据计算等
│   │   └── config.ts     # 服务端专属配置：密钥、第三方服务凭证
│   └── shared/           # 前后端通用代码：参数校验规则、类型定义、通用工具函数
└── routes/
    ├── api/              # 所有后端API接口，统一用+server.ts文件实现
    │   ├── upload/+server.ts
    │   └── compute/+server.ts
    └── 其他业务页面路由

几个必须遵守的规则：

• $lib/server（也就是src/lib/server）是SvelteKit强制隔离的目录，只要你在客户端可运行的文件（+page.svelte、+page.ts、+layout.ts等）里引入这个目录下的代码，构建时会直接报错，从机制上阻止泄露
• 所有带.server.后缀的文件，不管放在仓库哪个位置，都会被框架识别为仅服务端文件，同样禁止客户端引入，你可以给零散的服务端工具文件加这个后缀做双重保险
• +page.server.ts、+layout.server.ts、+server.ts这三类路由文件天生只在服务端运行，写在里面的逻辑不会打包到客户端
• 不要随便在src下新建无约定的目录（比如src/utils/）放敏感代码，这类目录没有框架隔离保护，万一误引入到客户端不会触发构建报错，很容易漏到线上

2. 验证敏感代码未泄露的技术手段 #

除了手动grep构建产物，这几个方法更可靠：

• 依赖框架自带的构建校验：执行npm run build时，只要出现客户端引入服务端代码的情况，会直接抛出构建失败错误，根本生成不了可部署产物，这是第一道也是最有效的防线
• 校验构建产物的依赖分离：用Node适配器构建后，产物会自动分成client（客户端静态资源）和server（服务端运行代码）两个目录，你可以写个简单的构建后脚本，检查client目录下的JS文件是否引入了服务端专属依赖（比如bcrypt、数据库驱动、Redis客户端这类只在服务端用的包），如果有就直接阻断部署
• 敏感关键词扫描：把你所有的敏感凭证特征（比如数据库连接串前缀、私钥头部标识、管理员账号名规则）加到构建后扫描脚本里，批量扫client目录下的所有文件，命中就告警，比手动grep覆盖更全
• 真实运行态校验：本地启动构建后的生产版本，打开浏览器开发者工具的Sources面板，遍历所有加载的JS资源，确认没有敏感逻辑——这是最贴近用户真实访问场景的检查方式，能覆盖所有构建规则没拦住的边缘情况
• 从根源隔离配置：所有敏感配置全部用SvelteKit的服务端环境变量规则，只有以PRIVATE_开头的环境变量能在服务端代码中读取，客户端代码读取这类变量会直接返回undefined，从根源上避免密钥被带到客户端

最后提个CPU密集型任务的小注意点：如果单次计算耗时超过100ms，不要直接在API请求的主线程里跑，会阻塞其他用户的请求，可以同仓库写独立的worker脚本，用Node的worker_threads开子线程处理，或者搭个轻量的内存队列排队执行，完全不用拆成独立项目，维护成本和纯单体没区别。

内容的提问来源于stack exchange，提问作者gbro3n