生态选型
在 JSR/npm、原生 API、Fresh 与 Node 框架之间按约束做决策
依赖来源
| 需求 | 倾向 | 检查 |
|---|---|---|
| TypeScript 原生库、标准库 | JSR | exports、文档、版本策略 |
| 成熟 Node 生态库 | npm | Node API、install scripts、原生扩展 |
| 小型 HTTP 服务 | Deno.serve + Web API | 路由、认证、校验是否需要框架 |
| Deno 原生全栈 | Fresh | 当前版本、islands、部署目标 |
| 迁移既有 Express/Hono 等 | 先保留框架 | 运行测试与部署适配器 |
决策问题
- 目标运行时是 Deno CLI、Deno Deploy、浏览器还是多个平台？
- 依赖是否要求 Node-API、postinstall、
node_modules或系统库？ - 团队是否已有框架经验与可观测性集成？
- 权限能否限制到具体 host、路径和变量？
- 包的维护、许可、发布者和供应链风险是否可接受？
没有“Deno 项目必须只用 Deno 原生包”的规则。优先复用仓库现有架构，用测试决定兼容性，用维护成本决定是否替换。
官方入口：JSR、npm compatibility、Fresh。