【已定位真因并自行解决】500000001 不是网络问题，是客户端硬编码 1MB 应答上限 跟帖折腾

【已定位真因并自行解决】500000001 不是网络问题，是客户端硬编码 1MB 应答上限

跟帖折腾了很久的各位，我用日志+逆向把这个问题挖到根了，官方请重点看第 3 部分。

1. 真因

桌面客户端 serverapi 包里对应答体大小硬编码了 1MB（0x00100000）上限，共分布在 24 个接口的解码路径里（CreateSession、decodeV3[SessionID]、readMessageGroups、ListMemoryPages 等）。本地历史会话数据较大的账号，session.start 的应答超过 1MB，客户端直接拒收，再被包装成“网络异常 500000001”。与网络无关，重装/换网/清代理全部无效。

2. 证据

app-server 明文日志（%APPDATA%\WPS 灵犀\logs\app-server\app-server_日期.log）可见真实错误：session.start 失败 err="server API response too large"，前端包装为 rpc -32603“网络异常(500000001)”；

重现条件：账号本地单会话数据超过 1MB（我这边单会话 rollout 达 155MB，100% 必现）；

对 exe 逆向确认：24 处 mov esi, 0x100000 / mov qword [rsp+0x10], 0x100000 形式的 32 位立即数。

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

服务端：对大账号的 session.start 应答做分页/分块返回；

客户端：把应答上限调大（建议至少 64MB，或改为流式读取）；

无论哪种，请把 500000001 的错误文案改为真实错误信息，“response too large”包装成“网络异常”让全网用户和客服排查了几个星期都在错误方向上。

4. 我的临时方案（供其他受困用户参考，有动手能力再看）

二进制补丁把 24 处上限常量 1MB → 256MB（总差异仅 50 字节），同时必须同步更新 .hash 指纹文件，否则客户端启动校验发现 exe 被改会静默恢复原版（这是很多人“补丁没生效”的原因）。补丁后 500000001 完全消失，客户端正常工作。

注：1.3.22~1.3.27 各版本均存在此问题（常量位置一致）。希望官方尽快修复，重度用户真的等不起。