H3 社区生态

官方在工具函数章节专门留了一页给社区库。这一页本身只是清单，没有技术内容，但它回答了一个实际问题：H3 缺的能力，哪些已经有人做了。

以下六个是目前列在 v2 兼容清单里的项目（2026-10-30 核对）。

六个社区项目

把它们按「补什么」分类，会更好判断要不要引入：

三条选型建议

第一，先确认 v2 兼容。 H3 v2 有大量破坏性变更（createApp 变成 new H3()、send* 改成 return、event.web 改名等，见 8.1）。一个库如果还写着 defineEventHandler，装上来大概率跑不通，而不是「能用但过时」。

第二，看它把依赖声明的哪一栏。 像 crossws 这种 peer 依赖，意味着库假定你自己装、自己控制版本（5.2 遇到过同样的问题）。如果社区库把 H3 声明成 peer 依赖，升级 H3 大版本时你会遇到版本冲突，需要主动对齐。

第三，别为了一个小功能引入一个框架。 上表里三个是「框架级」项目（H3ravel、Clear Router、Arkstack），它们会接管路由组织方式甚至项目结构。如果你的需求只是「加个 JWT」，选 unjwt 这种单一职责的库就好。

⚠️ 社区库不在 H3 官方维护范围内，安全相关的组件（JWT、会话、认证）建议先读一遍源码再上生产。清单本身也会变——官方页只是占位，实际可用性以各项目仓库为准。

想把自己的库列上去

官方明确写了「欢迎 PR」。提交时值得准备三样东西：一句话定位、一个能跑的最小示例、以及明确的 v2 兼容声明——评审时这三样比 README 长度重要得多。

延伸阅读

• 官方内置的安全工具，够用就不必引外部库：见 6.6 安全工具
• 会话的两种实现路径（内置 session 与外部 JWT）：见 7.3 会话基础
• v1 到 v2 的破坏性变更清单：见 8.1 v1 到 v2 迁移：核心变更