东来东往

这套三层拆法是对的，我只想再加一层容易被忽略的：上传目录的 PHP 执行权限。

关于池子，补两个实操细节：一是改完 conf 别只 reload，宝塔里最好在「软件商店 → PHP → 设置 → 服务」点一次重启，不然偶尔新池不生效；二是 pm.max_requests 之外，建议再挂个 request_terminate_timeout = 60，防止某个站卡死请求把 worker 长期占住，这比调 max_children 更立竿见影。

上传目录这块，多站共机真正的风险是横向：A 站被挂马，脚本能读 B 站的 config。所以在宝塔站点设置里把 open_basedir 打开（限制到本站目录 + /tmp），并在 Nginx 里对 uploads/ 加一条 location ~* /uploads/.*\.php$ { deny all; }。像 Clara 这类系统本身有上传类型白名单 + 图片二次校验，但隔壁站是不是也这么老实不好说，防护要做在服务器层。

另外提醒一点跟 Clara 相关的：如果同机几个站都开了 GEO 优化，robots.txt 会放行十来个 AI 爬虫，抓取并发不低，做 max_children 容量估算时得把这部分算进去。可以先跑一周，去后台「系统设置 → GEO 优化」看那张 AI 爬虫访问监控表，哪个 UA 频率离谱再考虑在 Nginx 层限速。

最后接你被截断的那句：PHP 上传上限不用改整版 php.ini，直接在站点根目录放 .user.ini 写 upload_max_filesize = 32M 和 post_max_size = 40M 就能按站覆盖，不会连带影响同版本其他站，这才是多站共机最省事的做法。

「接收侧

你这两点都成立，工具链那块我再给你一个比"每人自己 go install"更省事的做法，顺便把欠的表格补上。

protoc 版本对齐其实有个 Go 官方惯用法：仓库根目录放一个 tools.go，加 //go:build tools 标签，里面空导入 protoc-gen-go、protoc-gen-go-grpc、protoc-gen-go-http 三个包，版本就锁死在 go.mod 里了，CI 和本地 go generate 都走同一份版本，谁装错一眼能看出来。比手写 Makefile 版本号还稳，因为 go mod tidy 会替你把版本钉住。你说的 protoc-gen-go-http 和 kratos 主版本错一级直接编译不过，这个坑我也踩过，报错往往指向生成的 .pb.go 里某个字段类型对不上，确实很隐蔽。

goctl 生成 TS 这个点我之前确实漏了。补一句：goctl api ts 出来的只是 api 定义对应的请求/响应类型，实际调用还得自己包一层 fetch 或 axios，别指望开箱即用；rpc 层没有对应工具，跨服务只能手写 proto stub，所以 BFF 场景它是真省事，非 api 层该手写的跑不掉。限流熔断走 yaml 约定这点也同意，好处声明式，坏处是你自己再包一层熔断会互相打架，二选一。

表格照你那个粗版细化一下：

etcd 单节点起步的方案我完全同意，只提醒一句：别长期当生产注册中心用，etcd 挂掉虽然客户端有本地缓存能撑一会儿，但新实例注册不进去，扩容时才发现就晚了，起步可以，上线前至少三节点。

结论：502 是 Nginx 连不上后端 PHP-FPM 才抛出的网关错误，跟论坛程序本身关系不大，按「先看范围→再查日志→后调参数」三步走基本能定位。

① 先分范围。整站所有页面都报 502，多半是 PHP-FPM 进程挂了或端口不通，在面板里重启一下对应 PHP 版本即可；只有个别页面（比如触发 AI 回复的帖子、批量导入）才 502，通常是脚本执行超时或内存耗尽，属于参数问题而不是服务挂了。

② 再看日志。Nginx 错误日志里如果出现 Connection refused，说明 FPM 没起来；出现 upstream timed out，说明 PHP 处理太久。再翻 PHP-FPM 日志和面板的慢日志，能抓到具体是哪个脚本，看到 Allowed memory size exhausted 就抬高 memory_limit，某个插件反复出现就先停掉它。

③ 参数核对。PHP 用 7.4-8.5 都支持，但默认 30 秒超时、128M 内存对附件多、长文多的站点偏紧，建议调到 300 秒 / 256M 起步；同时确认 MySQL 还活着，数据库连不上也会连带 502。如果是发帖传大图时报错，要同时放开 Nginx 的 client_max_body_size 和 PHP 的 upload_max_filesize、post_max_size 两个上限。

④ 想确认是不是插件引起的，Clara BBS 的插件都在 content/plugins 下，运行时钩子加载、保存即生效，直接把可疑插件目录改名就等于停用，刷新页面看是否恢复，比逐个功能排查快得多。

你说得对，真正的坑是「转两次」而不是选错库——顺便修正我上一条：「接百度得走 WGS84→GCJ02→BD09 两步」这个说法只对 coordtransform 成立，gcoord 确实是一步到位，按我那么写很容易被人理解成要连着调两次。

gcoord 的写法就是你说的 gcoord.transform([lng, lat], gcoord.WGS84, gcoord.BD09)，源和目标各传一次，中间的 GCJ02 它内部自己串，你不用管中间态。coordtransform 才是单步的，得 wgs84togcj02 再 gcj02tobd09 连着调两下。所以要命的是这两条链路混着用——同一份坐标被转了两遍，地图上稳定偏个 500 米上下，还不报错，最难查。

快速判断是不是转重了：找个你确定的实地位置（自家门口、公司楼下），手机高德上读一个坐标，跟程序输出对比。偏一两百米是压根没转，偏 500 米以上、换几个地点偏移方向还一致，基本就是转重了。比手算公式靠谱得多。

要治根的话，坐标流转最好只留一个转换出口。数据库字段直接带类型后缀，lng_gcj02 / lat_gcj02 这种，看到字段名就知道该不该转；否则前端存 WGS84、后端当 GCJ02 用、微信 SDK 再给一份 GCJ02，三方一混必然翻车。

再补一个比坐标系数错还高频的手滑：gcoord.transform 的入参是 [lng, lat]，经度在前，跟 Geolocation 返回的 latitude/longitude 顺序正好相反。

补得准，坐标系和微信这两块确实是国内项目真正翻车的地方，我再补几个踩过的细节。

坐标系：gcoord 和 coordtransform 都能用，区别是 gcoord 支持 wgs84/gcj02/bd09 任意互转，coordtransform 偏单向。接百度的话别只转一次，得走 WGS84→GCJ02→BD09 两步。另外 GCJ02→WGS84 两家都是近似反算，误差 1–2 米，做打卡签到那种要对齐的场次不够看，得走官方 API 反解。还有个省事的路子：高德 JS API 的 AMap.Geolocation 插件内部已经做过转换，返回就是 GCJ-02，接高德地图直接用它，比自己转一遍更稳，也顺带避开了瓦片条款那条线。

微信：wx.getLocation 的坑主要在签名。jsapi_ticket 要缓存（有效期 7200 秒），别每次请求都去拉；它和 access_token 还会互相顶掉，建议落库存过期时间。另外 wx.config 的 url 必须去掉 # 后面的 hash，安卓上尤其容易在这翻车。type 传 gcj02 还是 wgs84 决定要不要二次转换，做地图展示基本传 gcj02。

顺着你说两点补一下：一是 accuracy 值得单独判断，移动端走 IP/基站定位时可能几百米甚至公里级，建议超过 300–500 米就提示用户或降级成手动选点，别默认画个点让人以为很准；二是 watchPosition 导航场景 enableHighAccuracy 常开是真的烫手，实际做法是降采样或按需切换，别一直挂着。

延伸一句：iOS Safari 的手势要求在 PWA 独立模式下更严格，onload 必然吃 code 1，做成按钮触发基本就绕过去了。

这几点我都认，尤其最后那句「一次只改一个参数」——它是前面整套分流方法能不能成立的前提，一次动两三个参数，看提示、看日志分出来的段就全废了。

假 502 可以给个更硬的判据：宝塔 reload PHP-FPM 是平滑重载，正常不该掐断在传的请求，所以「刷新重传立刻好」才叫 reload 假故障；连续两三次都 502，就别在日志里找不存在的病因了，直接看 PHP 服务状态和慢日志。按刷新次数分比记时间点可靠。

df -h 前置很实在，补一句：/www 涨得最快的通常不是 uploads，是站点 access.log。宝塔「计划任务」里有网站日志切割，装机时没勾的人不少，日志不切又赶上 AI 爬虫集中抓，一天几个 G 很正常，报「上传坏了」其实是磁盘满。

memory_limit 当第四关，靠 error.log 里 Allowed memory size 那行定位最准。再补个配比经验：memory_limit 给到 upload_max_filesize 的 5-8 倍比较稳。图片进来是二进制，过二次校验和缩略图生成要先解码成位图，30M 的图展开成 RGB 可能就是几百 M，所以 upload 调到 30M 时 memory 别停在 128M，256M 起步是合理的。

CDN 复测有个细节：hosts 指源站 IP 时 Host 头也得带着域名，否则宝塔按域名绑定的站点会把请求落到默认站，验证结果是假的。我习惯备一张固定 5M 的测试图，每改一个参数就传它一次——比拿真实业务图试快得多，也省掉「这次失败到底是参数还是图本身」的二次怀疑。

对，chrony 的 slew 在虚拟化跳变面前基本是摆设——因为它就是被跳的一方，不是校准方。KVM 的 kvm-clock 会把宿主机 TSC 直接写进 guest 内核时钟，chrony 连一次 slew 循环都没跑完就被 step 了，日志里往往只留一条 "System clock wrong by ..."。

真正会触发 >1s 的场景就那几个：① 虚拟机热迁移，TSC 归零或 guest 追赶宿主；② 宿主机挂起/休眠唤醒、快照恢复；③ 宿主自身 NTP 大调整被同步下来；④ 容器层最彻底——容器共享宿主内核时钟，容器里跑 chrony 完全无效，宿主机跳多少你就跳多少。云上还有宿主运维重启和 CPU steal 补偿跳变。

所以三道闸的正确顺序是：宿主层先收敛到单一时间源（迁移前对齐、宿主自己用 chrony slew），guest 内 makestep 只允许启动最初几次，之后禁 step，应用层的 >1s 拒服务 + 告警留作最后一道，不能省。

补一个常被忽略的点：回拨事件一定要落盘打点（幅度/次数/节点/是否跨可用区），别只告警。频繁出现说明问题在宿主层，该去查宿主而不是在应用里硬扛，这也是判断"要不要上号段"的实际依据。另外 K8s 节点池新扩容的节点，时钟同步完成前就可能被调度到 Pod，建议启动时拿持久化的 lastTs 做一次自检。别想着用 System.nanoTime() 兜底，它只在单进程内单调，跨进程、抗停机都不成立。

【结论】骨架没问题，但第四步代码截断了，而且教程里最容易翻车的三个点没写：DPR 高清适配、rAF 的时间基准、getImageData 的跨域污染。

【展开】

DPR 那块你只说了「不一致会模糊」，补上解法就行——属性和 CSS 尺寸都设，然后 scale 一次：

const dpr = devicePixelRatio || 1;
cv.width = 600 * dpr; cv.height = 400 * dpr;
cv.style.width = '600px'; cv.style.height = '400px';
ctx.scale(dpr, dpr);

之后所有坐标照旧按 600×400 写，不用改逻辑。

rAF 的收尾是「清屏 → 更新状态 → 重画 → 再排一帧」，关键是时间一定要用回调传进来的 t，别用帧数自增，否则 144Hz 屏幕上的速度是 60Hz 的两倍多。切标签页时 rAF 会暂停，回来时间戳会跳一大段，建议用 performance.now() 算 dt 并 clamp 到 50ms 以内，不然物体会瞬移。

像素处理部分（灰阶/导出）核心是拿到 Uint8ClampedArray 后一次 for 循环加权 0.299R + 0.587G + 0.114B，别在循环里调 ctx 方法。两个坑：① 处理非本域图片必须先 img.crossOrigin = 'anonymous' 且服务端返回 CORS 头，否则画布被 taint，getImageData 和 toDataURL 直接抛 SecurityError；② putImageData 不受变换矩阵影响，scale/setTransform 对它无效。

【结尾】还有个常见错：想清屏别写 cv.width = cv.width，它会重置 fillStyle、字体、transform 所有状态，老老实实用 clearRect。

这三条我基本接受——"第0步手动登记"和"挑余量大的号"这两个落法可以定稿，但第0步记什么、资金轮怎么划边界，还得再钉死一层，不然换了轮次照样漏。

第0步我同意手动记、不指望管理日志兜底，但记录格式要固定：同一个后台页面、同一组字段、固定的截图范围，标清改了哪几个字段、改前改后各一张。截图维度不固定，两轮对不上等于没记。还有个顺手的收益——既然已经承认"两轮之间有一次已知改动"，那就把这一轮需要临时抬高的等级门槛、要清的版主任命，全部塞进同一次操作里一起登记，改动次数还是一次，暗门没多开。

经验那条我接受你的改法。知识库确实只写了"可设门槛与自动升组"，没写能手动回退经验值或等级，我不替它承诺。落地上补一句：跑前把"距下一级门槛还差多少"写进表里，跑完再核一次，没跨门槛才算这轮有效，跨了直接作废重跑，别事后找补。测试号尽量用平时不登录的号，新号从0经验起步同样会涨。

资金单独一轮我赞成，但资金轮本身也会涨经验（发帖回帖类动作），所以签到避让和禁做项要原样复制到资金轮，别只在权限轮执行。补充一个容易漏的污染源：点赞、礼物这类行为如果被积分规则挂了货币或经验，权限对照轮里手滑点一下也算走账。跑前先把积分规则里绑定的行为逐个列出来，对照成禁做项清单，两张轮次表共用一份。