[C-06][medium] 推送时 meta 里的数字被转成 float64，超过 2^53 的整数被静默篡改 #37

New Issue

2026-09-30T13:56:59+08:00

nixevol commented

2026-09-30 13:56:59 +08:00

编号：C-06　严重级：medium　工作线：消息核心（internal/app/message、serve 的 messageLoops）　来源：审查 M-14
依赖：无　被依赖：无

结论与统一方案

采用审查 M-14 的方案：推送时用 protocol.Unmarshal（开启 UseNumber）解 meta；或者把 Msg.Meta 改为 json.RawMessage，直接输出入库的原文。推荐前者，改动只在消息包；后者要改 internal/protocol/types.go，需同步请 SDK 线核对解码。

雪花 ID、订单号等 64 位整数放进 meta 时，接收方拿到的值会被改掉。

改动文件

internal/app/message/dispatch.go（选后者还要改 internal/protocol/types.go）。

与其他问题的交互 / 冲突说明

与 C-01 同包不同函数。

验收与测试

meta 为 {"id":12345678901234567890} 时，推送帧里的数字逐字一致。

问题明细（各区审查原文，证据含文件与行号）

以下是本次复审各区审查报告的原文段落。A、M、I、P、S 开头的是原始发现编号（A 管理后台与网页、M 消息核心、I 身份认证群在线、P 传输平台部署、S SDK）。解决方案以本 issue 上方的"结论与统一方案"为准；原文里的方案与之不一致时，按上方执行。

[M-14] 推送时 meta 里的数字被转成 float64，超过 2^53 的整数被静默篡改

严重级：medium
分类：数据
现象与影响：
- 提交时 meta 按原样的规范 JSON 入库，数字保持原文。
- 推送时 decodeMetaJSON 用 json.Unmarshal 解到 map[string]any，数字变成 float64，雪花 ID、订单号等 64 位整数会丢精度，接收方拿到错误的值。
证据：dispatch.go:298-307；push.go:176。
文档依据：PRD F07 和 D11「自定义键值附在消息上」，送达的内容应与提交一致。
为何不是故意设计：DEVIATIONS 里没有相关说明。
解决方案：改用 protocol.Unmarshal（它开启了 UseNumber），或者把 Msg.Meta 换成 json.RawMessage，直接输出入库的原文。
改动文件：internal/app/message/dispatch.go（选后者还要改 internal/protocol/types.go）。
交互/冲突风险：改 protocol 类型需要总控同意；只改前者就在 M 目录内。
需补测试：meta 为 {"id":12345678901234567890} 时，推送帧里的数字逐字一致。
置信度：代码阅读确定。

_{复审基线：main 4059a15（2026-09-30）。编号说明、各工作线的合并顺序、共享文件归属见总览 #7。}

**编号**：C-06　**严重级**：medium　**工作线**：消息核心（internal/app/message、serve 的 messageLoops）　**来源**：审查 M-14 **依赖**：无　**被依赖**：无 ### 结论与统一方案采用审查 M-14 的方案：推送时用 `protocol.Unmarshal`（开启 `UseNumber`）解 meta；或者把 `Msg.Meta` 改为 `json.RawMessage`，直接输出入库的原文。推荐前者，改动只在消息包；后者要改 `internal/protocol/types.go`，需同步请 SDK 线核对解码。雪花 ID、订单号等 64 位整数放进 meta 时，接收方拿到的值会被改掉。 ### 改动文件 `internal/app/message/dispatch.go`（选后者还要改 `internal/protocol/types.go`）。 ### 与其他问题的交互 / 冲突说明与 C-01 同包不同函数。 ### 验收与测试 meta 为 `{"id":12345678901234567890}` 时，推送帧里的数字逐字一致。 --- ### 问题明细（各区审查原文，证据含文件与行号） > 以下是本次复审各区审查报告的原文段落。A、M、I、P、S 开头的是原始发现编号（A 管理后台与网页、M 消息核心、I 身份认证群在线、P 传输平台部署、S SDK）。**解决方案以本 issue 上方的"结论与统一方案"为准**；原文里的方案与之不一致时，按上方执行。 #### [M-14] 推送时 meta 里的数字被转成 float64，超过 2^53 的整数被静默篡改 - 严重级：medium - 分类：数据 - 现象与影响： - 提交时 meta 按原样的规范 JSON 入库，数字保持原文。 - 推送时 `decodeMetaJSON` 用 `json.Unmarshal` 解到 `map[string]any`，数字变成 float64，雪花 ID、订单号等 64 位整数会丢精度，接收方拿到错误的值。 - 证据：`dispatch.go:298-307`；`push.go:176`。 - 文档依据：PRD F07 和 D11「自定义键值附在消息上」，送达的内容应与提交一致。 - 为何不是故意设计：DEVIATIONS 里没有相关说明。 - 解决方案：改用 `protocol.Unmarshal`（它开启了 `UseNumber`），或者把 `Msg.Meta` 换成 `json.RawMessage`，直接输出入库的原文。 - 改动文件：`internal/app/message/dispatch.go`（选后者还要改 `internal/protocol/types.go`）。 - 交互/冲突风险：改 `protocol` 类型需要总控同意；只改前者就在 M 目录内。 - 需补测试：meta 为 `{"id":12345678901234567890}` 时，推送帧里的数字逐字一致。 - 置信度：代码阅读确定。 --- <sub>复审基线：main `4059a15`（2026-09-30）。编号说明、各工作线的合并顺序、共享文件归属见总览 #7。</sub>