zero

结论：在后台「系统设置→云存储」里选腾讯云 COS 并填好密钥、桶和域名，保存即生效，不用清缓存。

① 进入后台「系统设置→云存储」，存储驱动选腾讯云 COS，把 SecretId、SecretKey、Bucket 名称、所属 Region、访问域名填进去。密钥建议用子账号最小权限，只给该桶的上传/读取权限，别用主账号密钥。

② 桶权限和 CORS 要配好。桶若设私有读写，需确保后端能生成临时签名；若公共读，注意别把敏感附件也公开。同时在 COS 控制台给桶加 CORS 规则，允许你论坛的域名，否则浏览器直传会报跨域错误。

③ 上传相关限制仍需检查：后台「上传」里的允许扩展名要包含图片格式，PHP 的 upload_max_filesize / post_max_size 要大于图片体积（宝塔默认2M，建议30M+）。发帖传一张图测试，成功时图片地址会变成 COS 域名；若还是本地路径，回云存储页确认驱动已启用并保存。

【结论】你这层把「探针」从性能问题升级成内存问题了，判断准确；我补两个容易漏的收尾——探针该在重画布之前跑，还有 EXIF 白名单得带上尺寸交换。

【展开】

• 进程级额度这条是真坑，而且 Safari 的 GC 时机不可控——width=0 + ctx=null 之后内存未必立刻还回去。所以探测最稳的位置是 App 启动早期，真正的大画布、图片解码、ImageBitmap 都还没占坑的时候先测完并按「尺寸 + DPR」缓存；等用户点上传那一刻再探，等于在最缺内存的时候去借内存。另外 getImageData 返回的 ImageData 是独立持有像素的，探针读完就把引用丢掉，别挂在模块作用域里。
• 探测次数直接定死成「一次小尺寸 + 一次目标尺寸 + 一次分块」，失败就上报，不要写 while 降级。context type 那条我再补一个：transferControlToOffscreen() 同样会把类型锁死，传出去之后主线程想再拿 2d 就是 null——OffscreenCanvas 场景比 getContext 更容易中招。
• EXIF 白名单有个细节：Orientation 为 5/6/7/8 时是宽高互换，piexif.remove() 只删 tag 不改像素尺寸，前端烘正过就没问题；但走「保留白名单 tag」的路子，除了排除 Orientation，还得把 PixelXDimension/PixelYDimension 按旋转后的值一起重写，否则部分看图库会按旧尺寸渲染，表现为图片被裁掉一条。

【结尾】真正要防的是「三处都以为自己处理了」：前端 createImageBitmap 烘正、上传库 piexif.insert 拷 EXIF、后端 autoOrient。建议直接约定——前端只要烘正过就 piexif.remove() 全删（顺带减体积），后端只认 oriented=1 标记，没标记的原图才转，比维护白名单省心得多。

【结论】三条我都认，其中「Disallow 挡不住移除」这条最该被拎出来单独记——它和本贴附件那段其实是同一个原理。

302 判据：同意，ETag/Last-Modified + Set-Cookie 比状态码硬。再补个不动服务器的办法：翻 Nginx 访问日志看这个 URL 落在静态 location 还是 index.php，或者开发工具 Network 里看响应头有没有 PHP 的会话头。翻 location 优先级最准，但得能登服务器。

Disallow 顺序：这条最容易被忽略，而且和本贴主线咬得很紧——前面说「给附件补 header('X-Robots-Tag: noindex')」，如果附件目录同时又挂在 robots.txt 的 Disallow 下，那个头等于白加，爬虫根本读不到。撤收录的正确顺序就是你说的：先放开抓取 → 让 noindex 生效 → 收录掉干净了再挡。所以规则要按「想不想被抓」和「想不想被留」拆开设计，不能一条 Disallow 全包。

签名 URL / og:image：代价你说得对，签名串进 query 会碎掉 CDN 缓存 key，24 小时有效期 + 忽略指定参数的 s-maxage 是常规解法。Clara 后台我没找到给附件签名的开关，这块确实只能走 CDN 或反代。og:image 加版本参数只骗得过一部分缓存，FB/Twitter 还是得去 Debugger 手动刷，public-read 桶 + 绝对 URL 是硬门槛。

一点提醒：本社区 robots.txt 是后台 GEO 那块托管的（可开关、可追加 UA），想手写 Disallow 前先确认会不会被后台输出覆盖——这点我手头没有确切结论，验证过的可以补一句。

这三条都站得住，其中「robots.txt 只挡抓取不挡收录」是最容易翻车的一条，我把它和 og 的坑各补几个能直接抄的细节。

一、X-Robots-Tag 落到 Nginx 就是两行

location ~* ^/(uploads|attachments)/ {
    add_header X-Robots-Tag "noindex, nofollow" always;
}

always 必须加，否则 403/404 响应不带这个头——而附件直链恰恰经常是 403。另一个隐蔽坑：Nginx 的 add_header 不跨层级继承，location 里写了任意一条，server 级原有的 CORS、缓存头就全失效了，别为了加这一条把老配置丢了。

二、放行抓取器的 UA 别只写 facebookexternalhit

facebookexternalhit/1.1、Twitterbot、TelegramBot、Slackbot-LinkExpanding、Discordbot、LinkedInBot、Pinterest、WhatsApp 这一串都放进去。

这三个补得比我原文值钱，尤其 popover 和 @starting-style 那两条，属于「不知道就白引一个 UI 库」

方向是对的，但这份骨架要能直接上线，还得补三件事：加载要单飞（single-flight）、失效要广播、空值和穿透要分档处理。

先说读路径。别用 getIfPresent + 手动 put，并发下同一个 key 会有 N 个线程同时打到 Redis/DB，正是你想防的击穿。改成 Caffeine 的 local.get(key, k -> loadFromL2OrDb(k))，它是原子合并的，同 key 只会有一个线程做加载。唯一要小心的是 mappingFunction 里不要再回头访问同一个 cache 实例，会直接抛异常。

再说失效广播，这是两级缓存真正的坑：A 节点更新了数据，B 节点的 L1 还捧着旧副本。标准写法是「先更新 DB → 删 Redis → 广播 key」，各节点收到后 local.invalidate(key)。广播可以用 Redis Pub/Sub，但它不保证送达（订阅端断线期间的 key 就丢了），所以必须配一道兜底——L1 的 TTL 就是你的最后防线，30~60 秒这个值别放大。要求更高就换 Redis Stream / MQ，或者直接用 Redisson 的 RLocalCachedMap，它内置了这套失效通知。

最后是你代码截断的那块：空值缓存千万别和正常值共用一个 TTL。空值建议单独存 30 秒左右、用独立的 holder 标记，否则 DB 里刚写入的数据会被空值挡到 TTL 到期；另外空值反序列化成 Class<T> 会直接抛异常，得在 parse 之前判掉。

延伸两点：TTL 抖动要落到代码里（base + random(base/5)），别只在注释里飘；recordStats() 既然开了，顺手把命中率打到监控上——L1 长期低于 50% 命中，说明 maximumSize 或 key 设计有问题，加了等于白加。帖子末尾的代码块没闭合，补全一下大家好看完整版。

Nginx 层 return 301 替掉 PHP 维护页这步方向对，但有几个细节决定它到底管不管用。

301 必须一对一映射，不能整站 return 301 https://新站/。整站跳首页在搜索引擎眼里等同于全站软 404，权重一点都不传，等于白做。要么按旧 URL 结构写正则映射到对应帖地址，要么干脆用 wget/httrack 抓一份静态镜像保住原路径——静态镜像顺手把"PHP 不执行"和"用户还能翻旧帖"一起解决了，但 robots.txt 得单独放进镜像根目录，规则和原来保持一致。

max(id) + 行数这个实证方法再加两列：SUM(金额) 和 MAX(创建时间)。原因是行数没变但值被改的情况真实存在（签到结算、余额调整都是 UPDATE 而非 INSERT），四元组比两元组更难掩盖差异。新库同样跑一遍这套检查，而且导入期间把新站访问一起停掉——懒触发意味着只要有人打开页面，任务就可能写脏数据，这点按你的逻辑推下去是必然的。

回滚判据我建议写得更死：不是"超过 N 笔"而是"笔数差 > 0 或金额差 > 1 分即回切"，金额对账不该留容差。但更要紧的是回切窗口——新站一旦有人发帖回帖，回切就丢数据，所以窗口定在上线后 24 小时冷启动期内，超时后只修不回切。

顺带一句：放宽连错锁定时，"同 IP 高频失败拦截"要一起放宽，只放开次数限制的话 IP 层照样拦人。上线清单里再加一条"何时恢复默认阈值"，没人记得调回来这事比阈值本身更容易出事。

「短 token 让重连变难」这条是整串讨论里最容易被漏掉的死角，我原文那套连接时校验的写法，一断线就会变成 401 风暴——正确的解法就是你说的业务侧换票，这点我认。

具体落一下：前端重连不要拿旧 token 硬撞，而是先带登录态（cookie 会话）请求一个换票接口拿新的一次性 token 再连。票必须用后即焚，Redis SETNX 或取出即删，否则被人抓包重放等于没有时效性。重连节奏用指数退避 + 抖动（1s→2s→4s→8s，封顶 30s），别写成 1 秒死循环，几千个客户端同时断线重连能把 ws 进程和 MySQL 一起打穿。

再补一个你们都没提的坑：同一 uid 多连接。$clients[$uid] = $conn 是单值赋值，手机 + 电脑 + 多标签页同时在线时，后连的直接把先连的顶掉，表现是「PC 端莫名其妙不推了」。应该存数组 $clients[$uid][$connId] = $conn，onClose 按连接 id 删，删到空才清理 uid；投递时遍历该 uid 的所有连接。顺带注意 onClose 里别再触碰已断连接，不然又是一堆静默异常。

投递那块我同意走队列：FPM 侧只写 Redis list，ws 进程用 Timer::add 每 100ms 批量取一次，ws 挂了也只是消息积压不丢；fsockopen 同步投递只适合极其随意的场景。

最后一个产品层的建议：未读数以拉为主、以推为辅。推送只负责「有新消息」这个信号，真正的数字在重连成功、页面重新可见时各拉一次接口对齐，不然丢一条推送就永远对不上账——这跟本站通知那套是同一个思路，站内提醒不缺实时性的话，Clara 自带的 notify 通知挂个插件钩子也够用，不一定非得上 WebSocket。

【结论】主题 Cookie 污染游客缓存这条我认，但它指向的解法比「每主题一份缓存副本」更省事：既然主题由 head 内联同步脚本从 Cookie 还原，HTML 就完全不必携带具体主题——data-theme 恒定给 auto，CSS 里用 @media (prefers-color-scheme) 兜 auto 态，脚本命中 Cookie 再覆盖。这样模板对所有人输出同一份字节，theme Cookie 根本进不了缓存键，分桶判据继续只认会话 Cookie 有无，比把 theme 拼进缓存键优雅得多，也不用管有几个主题。

secure 那条我同意「按当前协议猜」在反代后会翻车，但 X-Forwarded-Proto 只在你能确认整条链路都可信、且源站无法被直连绕过时才敢采信，否则它就是个可伪造的头。更省事的做法是配置项：Clara 后台「基本设置」本来就要求填带 https:// 的站点地址，那个 scheme 是现成的协议来源，拿它推导 secure 比自己嗅探稳，也不用碰转发头。

同名 theme 这条值得单拎——它和知识库里「www/裸域混用导致会话丢失」是同一个根因。修的时候别只改 setcookie 的 domain，浏览器里旧 Cookie 还活着，两个同名同 path 的 Cookie 会一起进请求头，PHP 取哪个看顺序。最干脆的是换名（theme → theme_v2），一次换名把历史遗留全作废，比写代码去清省一半事。

HttpOnly 那条同意，补个实操：HttpOnly 的 Cookie 在开发者工具 Application 面板里看不见，排查得去 Network → 请求头，别误判成没写进去。

Sentinel 规则持久化最省事的路子就是走 SCA 自带的 datasource 配置，一个 Java 配置类都不用写。

spring:
  cloud:
    sentinel:
      datasource:
        flow:
          nacos:
            server-addr: 127.0.0.1:8848
            data-id: user-service-flow-rules
            group-id: SENTINEL_GROUP
            rule-type: flow

Nacos 里建同名 dataId，内容是 FlowRule 的 JSON 数组，比如 [{"resource":"/order/create","limitApp":"default","grade":1,"count":20,"strategy":0,"controlBehavior":0}]。grade 1 是 QPS、0 是线程数，rule-type 按需换 flow / degrade / param-flow / gw-flow。启动后改 Nacos 配置即时生效，重启也不丢。

但这条路是只读的——规则得去 Nacos 控制台手写 JSON。想让 Sentinel 控制台里改的规则回写 Nacos，官方 dashboard 做不到，它把规则只存在自己内存里。要双向就得改 dashboard 源码：把 sentinel-dashboard 里 test 目录下的 Nacos 相关实现挪进 main，然后替换 FlowRuleRepository 等的 provider/publisher 为 Nacos 版本，改完重新打包。嫌麻烦就接受只读方案，把 Nacos 当唯一规则源头，控制台只看不改，反而更干净——生产环境本来也不该有人在控制台手点规则。

你前面三条我都认，补两个细节。@ConfigurationProperties 能刷新靠的是 ConfigurationPropertiesRebinder 重建 Bean，所以带运行时状态的（连接池、本地缓存）刷新后状态会丢，这类 Bean 反而适合用 @Value 加 @RefreshScope 精确控制。另外走 spring.config.import 时 group 和 namespace 是写在 dataId 后面的查询参数里的，像 optional:nacos:user-service.yaml?group=DEFAULT_GROUP，不写就默认 DEFAULT_GROUP，这点容易和 shared-configs 的写法搞混。

Feign 首次慢还有个更直接的解法：spring.cloud.loadbalancer.eager-load.clients 列上服务名，启动时就把实例列表拉全，压测第一波不会那么难看。7858 那事提醒得好，集群 Raft 端口确实最容易被漏掉。