Hatamoto 后端全面迁移至 Go 的 encoding/json/v2，新 v1 导入无法通过检查

Hatamoto 的后端现已运行在 Go 的 encoding/json/v2 上，任何新的 v1 导入都无法通过检查。空列表返回为 []，请求校验更严格，webhook 与插件的字节保持不变。 今天，Hatamoto 全面迁移到新发布的 JsonV2 Hatamoto 的 Go 后端不再使用最初的 encoding/json 包。我们把 HTTP 层、内容存储、平台服务、插件宿主与 SDK，以及测试和工具链都迁移到了 encoding/json/v2。后端中任何新的 v1 导入现在都会让 make check、pre-push 钩子和 CI 失败。这项改动已在 hatamoto.dev 上线，并将在下个版本随自托管安装包发布。最可能的候选版本是 V1.0.9 v2 包随 Go 1.25 引入，需要开启 GOEXPERIMENT=jsonv2。我们基于 Go 1.27 构建，发布构建不设置任何实验性标志。 REST、admin 和 MCP 响应在遇到空列表或空 map 时返回 [] 和 {}，而过去返回的是 null。如果你的客户端检查 null，请改为检查空列表。读取 hatamoto ... --json 输出的脚本同理，这些输出也不再转义 <、> 和 &，MCP 工具输出的文本也是如此。 请求体校验更严格。重复的成员名、无效的 UTF-8 或 JSON 值之后的多余数据都会被拒绝。成员名按大小写敏感匹配，这在 v1 中从未有过：写成 Title 而不是 title 通常会被忽略，少数端点会以 400 拒绝。 Webhook 请求体及其 HMAC 签名保持不变，宿主与 WASM 插件交换的字节也保持不变。改动它们会破坏任何校验签名的接收方，因此这些路径走一组固定的选项，复现 v1 的输出。唯一的不同：如果某个插件类型有两个字段共享同一个 JSON 名，现在序列化会失败，而不是静默丢弃这两个字段。 因此这次 JSON 迁移不会破坏用 SDK 0.5 到 0.18 构建的插件。同一版本中另一项独立的改动会停止加载请求已移除写权限的旧插件，并且如果某个包的 plugin.json 重复了字段名或把字段名拼写成了别的形式（用 allowedHosts 代替 allowed_hosts），现在会在安装时被拒绝。更新前请先阅读发布说明。SDK 0.19.0 需要 Go 1.27 或更高版本。 一次迁移会规范化已存储 JSON 中已知的混合大小写键，hatamoto doctor json 会报告任何无法通过严格读取的行。JSON 相关改动不会提高回滚的最低版本要求，因为上一个版本读取 [] 和读取 null 一样正常。同一版本中的其他改动有各自的回滚步骤，所以回滚前请先阅读发布说明。 后端代码统一经过一个小型内部包 internal/jsonx，其中为请求、存储数据、响应、HTML 内嵌 JSON 和固定线格式分别定义了命名的选项集。贡献者指南说明了该用哪一组。 有三个文件仍有意导入 v1：两个 shim 用于读取 v1 的旧版兼容选项以构造固定选项集，以及一个冻结在旧编码器上的测试插件。数据库迁移不受此限制。后端其他任何地方，v1 导入都会导致检查失败。 机器人工程师、单口喜剧演员和创业者。我深切关注开源与安全，曾为许多开源库做出贡献，并经营一家代理机构约 20 年。