SvelteKit搭配adapter-node部署生产环境的实现方案咨询

两种方案没有绝对的优劣，需要根据你的项目场景选择，绝大多数生产级项目更推荐自定义entryPoint接入Node框架的方案，具体对比和落地经验如下：

两种方案优劣势对比 #

方案1：自定义entryPoint接入polka/express等框架 #

优势：

• 性能更好：静态资源、预渲染页面的相关处理逻辑（安全头、压缩、缓存规则）在Node服务层直接生效，不需要走SvelteKit的runtime和hooks链路，静态资源请求的开销大幅降低，高并发下性能优势更明显
• 生态适配成本低：可以直接使用Node生态成熟的中间件，比如helmet、compression、限流、日志类中间件都可以直接接入，不需要额外适配SvelteKit的规则，踩坑少
• 扩展灵活度高：可以自定义服务启动逻辑，比如优雅关停、多端口监听、和其他内部服务集成都可以直接实现，没有SvelteKit框架的限制

注意点：

你给出的示例代码中间件顺序有误，compression需要放在kit相关中间件的前面才会对静态资源和页面生效，修正后的逻辑顺序应该是：

// src/server.js
import { assetsMiddleware, prerenderedMiddleware, kitMiddleware } from '../build/middlewares.js'
import polka from 'polka'
import compression from 'compression'
import helmet from 'helmet'

const app = polka()

app.use(helmet())
app.use(compression())
// 在这里可以加静态资源缓存中间件
app.use(assetsMiddleware, prerenderedMiddleware, kitMiddleware)

app.listen(3000)

方案2：在hooks.js的handler方法中实现 #

优势：

• 符合SvelteKit原生开发规范，不需要额外维护server.js和修改adapter配置，小型项目改造成本低
• 逻辑和SvelteKit请求链路强绑定，如果后续需要切换其他适配器部署到Serverless平台，安全、缓存相关逻辑可以直接复用，不需要修改适配层代码

劣势：

• 性能开销大：所有请求都需要走SvelteKit的hooks处理链路，静态资源请求也会多一层runtime损耗，高并发下性能差很多
• 实现成本高：默认handler不处理adapter-node托管的静态资源，你需要自己手写逻辑匹配静态资源后缀来加缓存、压缩规则，容易出现遗漏
• 生态兼容差：Node生态的多数原生中间件不能直接在hooks中使用，需要额外封装适配SvelteKit的handle规则，额外工作量大

生产落地最佳实践 #

1. 优先选择自定义entryPoint的方案，除非你的项目很小，或者有跨平台部署的需求
2. 预压缩优化：构建阶段直接生成gzip和brotli格式的预压缩文件，服务端使用对应的静态资源中间件直接返回预压缩文件，避免runtime压缩占用CPU资源
3. 缓存TTL配置：带哈希戳的静态资源（js、css、图片等）设置max-age=31536000, immutable的长缓存，html和预渲染页面设置短缓存或者协商缓存，避免更新不及时
4. 生产部署建议在Node服务前加一层Nginx做反向代理，静态资源直接由Nginx托管，Node服务只处理动态请求，性能可以进一步提升，安全规则也可以在Nginx层做一层兜底

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