【已逆向定位真因+建成自愈体系】500000001 不是网络问题，是客户端硬编码 1MB 应答上限

折腾几星期的各位，真因挖到底了，官方请看第 3 节。

1. 真因（exe 逆向实锤）

桌面客户端 serverapi 包对应答体硬编码 1MB（0x00100000）上限，分布在 24~25 处解码路径（mov qword [rsp+X] / mov esi 立即数）：CreateSession、decodeV3[SessionID]、readMessageGroups、ListMemoryPages 等。本地历史数据大的账号，session.start 应答超限，被包装成“网络异常 500000001”。与网络无关，重装/换网/清代理全部无效。

自查方法：打开日志 %APPDATA%\WPS 灵犀\logs\app-server\app-server_日期.log，搜 response too large——搜到就是这个问题，别再查网络了。

2. 官方版本时间线（一直没修）

1.3.22 ~ 1.3.27：24 处 1MB 上限 → 5.14.0（10-29 强更）：25 处，位置略移 → 5.15.0：仍未修。每次强更后原样复发。

3. 给官方的修复建议（任一即可）

① 应答改流式/分页返回；② 上限调 ≥64MB 或按内存动态；③ 最重要：别把 response too large 包装成“网络异常”——这个错误码让所有受困用户在错误方向上排查了几星期。

4. 我们的现状

已建成自动防御：文件事件哨兵（强更落盘毫秒级发现）→ 自动重打 25 处补丁（1MB→2GB，PE 校验和/时间戳隐身）→ .hash 同步防回滚 → 活进程热补丁免重启。连续两次官方强更（5.14.0/5.15.0）2 秒级自动接住，零人工。

受困用户可先按第 1 节自查确认根因，避免在网络层白耗时间。

灵犀反馈建议

19小时前

2 +1

【已逆向定位真因】500000001不是网络问题，是客户端硬编码1MB应答上限折腾几星期的各位，真因挖到底了。真因：桌面客户端serverapi包对应答体硬编码1MB上限，分布在24~25处解码路径（CreateSession、decodeV3等）。本地历史数据大的账号，session.start应答超限，被包装成“网络异常500000001”。与网络无关，重装、换网、清代理全无效。自查：日志%APPDATA%\WPS灵犀\logs\app-server\里搜response too large，搜到就是这问题，别再查网络。版本：1.3.22~5.15.0全存在，多次强更未修，重度用户反复中招。建议（任一即可）：①大应答改流式/分页返回；②上限调到64MB以上；③最重要——别把超限包装成“网络异常”，这个错误码让受困用户在错误方向排查了几星期。现状：我们已建成自动防御（毫秒级发现强更→自动重打补丁→指纹同步防回滚→热补丁免重启），上限已补至2GB稳定运行，连续两次强更自动接住、零人工。受困用户可先自查日志确认根因，避免在网络层白耗时间。求官方尽快修复！