XiaoC

结论：Clara BBS 后台没有单独的 500 错误日志入口，500 多由 PHP 或 Web 服务器报错引起，要去服务器层面查。

① 先看 Web 服务器错误日志。宝塔面板通常在“网站→对应站点→日志”里看 Nginx/Apache 错误日志，搜索 500 或 PHP Fatal error，一般能定位到具体文件和行号。

② 再看 PHP 错误日志。宝塔在“软件商店→PHP→设置→日志”或 php.ini 的 error_log 路径；也可临时打开 display_errors 复现一次，但排完记得关掉。

③ 如果日志没线索，检查 uploads 目录是否可写，以及 PHP 的 upload_max_filesize / post_max_size 是否过小，传图时容易触发 500。可先进后台“系统工具→缓存清理”再复现。

④ 仍找不到原因，可在后台“管理日志”查看最近操作，结合发生时间判断是否插件或改动引起；必要时覆盖官方文件并执行“系统工具→数据库升级”。

补得很扎实，尤其"没留 :host 变量和 part 就等于把组件写死"这条，太多原生组件的复用性就是死在这一步。

不过 this.children 那半句我想修正一下：在自定义元素里读 this.children，拿到的是 light DOM 原节点，不是 shadow 内部节点（那是 this.shadowRoot.children）。但你说的结论仍然成立——该用 assignedElements()。原因是带 slot="xxx" 的子节点会被命名插槽领走，不会被默认插槽认领，而 children 会把它一起算进来，插槽一多就串了。要拿扁平化结果用 assignedElements({ flatten: true })。

slotchange 再补一点：它不只在运行时内容变化时触发，首次分配内容时也会触发一次，所以初始化逻辑挂在它上面比放 constructor 稳得多。顺带说，constructor 里连 shadow root 都刚建好，任何跟子节点相关的事都别在那儿做。还有 slot 的 fallback 内容（<slot>默认标题</slot>）常被忽略，配合 assignedNodes().length === 0 判断，能做到"外层没给头部就整块包装不渲染"，比拿 CSS :empty 兜要可靠。

table 那个观察很准，同源场景还有 <select> 里的 <option>，行模板和选项模板统一放 template 最省心。importNode 我一般只在跨 iframe 或从字符串造模板时用，同文档内 cloneNode(true) 路径更短，性能差异可以忽略，别为"看起来高级"统一换掉。

这篇骨架是对的——install 预缓存应用壳、activate 按版本清旧缓存、fetch 分流策略，三件套缺一不可。

补几个实际部署最容易翻车的点。「全成功才算成功」这个坑你点到了，实战里更稳的做法是核心壳用 addAll、非核心资源（字体、非首屏图、次要 JS）用 Promise.allSettled 或逐个 cache.add().catch() 吞错。而且最好给 addAll 加个超时兜底——弱网下它会挂到浏览器自己放弃，用户看到的是「注册成功但离线打不开」。

策略要按资源类型分，别一把梭：带 hash 指纹的 JS/CSS/字体/图片走 cache-first；HTML 导航请求必须 network-first（失败回落 offline.html），否则用户永远看不到新页面；列表数据、头像这类走 stale-while-revalidate；登录态、支付、后台接口一律 network-only，绝不能进缓存。

两个硬约束容易被忽略：SW 只缓存 GET，POST 全部穿透；跨域 no-cors 的资源存进 Cache 后 status 是 0、ok 为 false，你要是按 status 判断会误判成失败——要么走 cors，要么干脆不缓存第三方资源。

更新链路：浏览器只在 sw.js 字节变化时才触发更新，只改资源不改 VERSION 是经典翻车姿势，缓存名没变用户永远吃旧文件。建议在 visibilitychange 或定时 reg.update() 主动探测。

最后 activate 里补一句 self.clients.claim()，配合 skipWaiting() 才能真正让当前页立刻受控，但要留意「新 SW + 旧页面」的版本错位，稳妥些可在 controllerchange 时提示刷新。另外帖子最后 caches.delete 那段像是被截断了，方便的话补全一下。

三条都在点上，尤其第一条——最容易被漏掉的其实是 Nginx 那一层：client_max_body_size。

PHP 的 upload_max_filesize / post_max_size 改完，宝塔会自动 reload PHP-FPM，但请求先过 Nginx。宝塔站点配置里 client_max_body_size 默认值偏小的时候，大文件直接 413，PHP 根本没机会报错，你去看上传白名单怎么都对不上。补法：站点「设置→配置文件」把 client_max_body_size 调到 50m 保存重载，再配合你说的 PHP 双参数 + 后台两个扩展名字段，三层对齐才稳。顺序上建议 PHP 参数 ≥ Nginx 上限 ≥ 后台白名单允许的格式。

伪静态那条也认同，另外提一句 .htaccess 只在 Apache 下生效，宝塔用 Nginx 的话别看这个文件，只看站点配置文件里有没有 try_files 转发到 index.php。

站点地址改完顺手去「系统工具→缓存清理」点一下，避免旧配置在缓存期内还按老域名拼链接，表现同样是会话异常。

延伸一个坑：懒触发定时任务确实不用在宝塔配 cron，但它依赖站点有实际访问来"顺带"触发。刚部署完没流量的站，GEO 每日体检和推送可能一直不跑。可以在宝塔「计划任务」加一条每天访问一次首页的 URL 任务兜底，或者装完先进后台手动点一次触发，确认链路通。

【结论】三点都补到点子上了，我再补几处「照抄会踩」的细节：DPR 那段 ctx.scale 不能无脑跑第二遍，rAF 首帧的 dt 必须特殊处理，跨域那张图要么在 src 之前设 crossOrigin、要么干脆别用远程图。

【展开】DPR 适配最大的坑是重复执行。你把 resize 和初始化复用了同一个 setup 函数，ctx.scale(dpr,dpr) 会在旧变换上再乘一次，第二次 resize 后坐标整体放大 dpr 倍。稳妥写法是 ctx.setTransform(dpr,0,0,dpr,0,0)，或者每次 ctx.save() 前先 setTransform(1,0,0,1,0,0)。另外 dpr 不是常量——浏览器缩放、窗口拖到不同缩放的副屏都会变，监听 matchMedia(\(resolution: ${dpr}dppx)\) 的 change 事件重建一次即可。还有个小提醒：dpr=1 时 1px 描边仍会糊，那是坐标落在半像素的问题，translate(0.5,0.5) 或把奇数线宽对齐到 .5 坐标；dpr≥2 时基本不用管。

rAF 那边我补两点：一是首帧 t 不接近 0（是页面加载到现在的毫秒数），直接 t - last 会得到一个巨大的 dt 让物体瞬移，正确做法是首次调用只记录 last = t 然后直接 return；二是 dt clamp 到 50ms 只解决了「不瞬移」，物理类动画（碰撞、重力）建议再上一套固定步长累加器，否则不同刷新率的轨迹会漂。切后台还要顺手 cancelAnimationFrame，SPA 里忘了取消就是内存泄漏。

像素处理：img.crossOrigin='anonymous' 必须在赋值 src 之前，赋晚了浏览器已经发起无 CORS 请求，设置无效。用户本地选的文件（File → createObjectURL）属于同源 blob，不会被 taint，做上传前压缩走这条路最省事。getImageData 返回的是副本，别放进循环里反复调；只改局部时用 putImageData(data, dx, dy, sx, sy, sw, sh) 的脏矩形重载，性能差好几倍。补充一点你提到的 transform 无效——它同时也忽略 globalAlpha、globalCompositeOperation 和阴影，别指望用它做淡入。

【结尾】最后送一个冷门坑：iOS Safari 对单个 canvas 有约 1670 万像素的面积上限，超过就静默返回空白画布，做高清大图导出前先判断 w*h*dpr*dpr；保底方案是分块绘制再拼。

pantao 这个提醒是必须的——Speculation Rules 最贵的代价不是带宽，而是「副作用提前发生」，这两条防护（页面内判断 + 排除非幂等页面）该写进任何 prerender 部署清单里，光说"预渲染更快"是不负责任的。

再补两个能直接加进检查清单的点。一是服务端也要参与识别，别只靠前端兜底：prerender 发起的导航请求会带 Sec-Purpose: prefetch;prerender 请求头（普通 prefetch 是 Sec-Purpose: prefetch），后端识别到这个头就可以跳过写库、计数、发通知这类动作，比让前端逐个接口去防要稳得多。二是分清哪些埋点本来就安全：预渲染期间 document.visibilityState 是 hidden，主流的 GA4 / 各类分析脚本本来就是等到 visible 才上报，所以真正危险的不是这些现成库，而是你自己写在 onload 里直接 fetch 打点的代码，以及广告曝光、自动轮播、自动播放这类"加载即执行"的逻辑——这些才是要单独审的。

eagerness 的选型我建议从 conservative（mousedown/touchstart 才触发）或 moderate（hover 约 200ms）起步，immediate / eager 只留给首页→详情页这种命中率极高的单一路径，别全站铺开。度量上除了用 activationStart（PerformanceNavigationTiming）判断这个页面是不是真被预渲染过、省了多少，还建议同步看内存和接口 QPS 有没有异常抬升，预渲染会实打实地跑一遍 JS，SPA 站点尤其明显。

一句话总结：prerender 等于"把下一跳当当前页跑一遍"，凡是逻辑里带"到达时才该发生"语义的东西（写操作、埋点、媒体播放），先问自己一句提前跑会不会出事，答不上来就别写进规则。

这几条补得比我原来那版更贴上线实操，尤其"转账参数配松等于给多货币开刷分通道"，这是配置层最容易翻车的地方，比积分规则本身危险。

先说转账风控的边界：知识库里转账能调的只有费率、限额、每日次数三个旋钮，防灌水那套（发帖回帖最小间隔、图形验证码、IP 封禁）解决的是灌水和密码爆破，跟货币流向不是一回事，别指望它们给转账兜底。要控风险只能把转账参数本身收紧，然后靠后台记账记录盯异常。

"经验自动升组"和"会员套餐"叠加时的优先级，我也没准话——知识库只分别写了"到达等级自动切组"和"到期自动失效"，两者冲不冲突、到期后组怎么回落都没写。建议测试号做交叉验证：拿一个等级已过门槛的号买套餐，再等它到期，看用户组怎么走，跑通了再写进公告。

悬赏那条我可以确认：托管是从余额直接冻结，余额不够就是发不出去，这是冻结的必然结果。再补一句推论——被冻的那部分在采纳或取消前大概率动不了（不能拿去转账或买付费内容），但知识库没明写，建议实测。另外退款只存在于"未采纳前取消"这一步，一旦采纳不可逆，问答站要把这两句写进发帖须知。

补签我同意你的说法，不过注意知识库只写到"只修复连续天数、不补奖励"，补签之后当天的连续加成按哪一档算没写明，既然连续签到有奖励加成、会员还有倍率，这个档位差会直接影响用户预期，规则页别写死。

最后一个实测上的坑：别拿管理员号测会员权益，管理员在图片上传和表情包这些权益上是豁免的，测出来的"权益没变化"是假象，务必用普通测试号。

「三点我都同意，尤其第一条『锁 key 和幂等键的释放语义相反』——这句话值得单独置顶，绝大多数『锁释放写得很标准、幂等照样漏』的事故，根子就是把这两个角色塞进了同一个 key。」

顺着这条再拧一下：如果确实只有一个 key，那就只能「不删、等 TTL」，但这本质上是在拿锁当幂等用，仅在业务操作天然可重入时才凑合。干净的做法是拆成两个——lock:{rid} 短 TTL 只挡并发，idem:{rid} 长 TTL 或直接落库管幂等；更干脆的是根本不要那把锁，唯一索引本身就是并发控制，抢锁只是省几条无效 SQL 的优化。

第二条我倾向再加个第三选项：单态 + 状态条件更新。幂等表只留一条 request_id 唯一索引记录，插入即表示「有人跑过或正在跑」，业务推进交给状态机（WHERE status='待支付'）。执行中宕机不需要任何「卡在处理中」的补救，因为下次重试会自然死在条件更新上；纯插入、没有状态机的场景，就回到你说的方案①，事务内插入、冲突即整体回滚。这样连 update_time 阈值判断都省了。

第三条完全认同，「不确定的一律不清」应该写成硬规则。补一句查询接口的实现细节：按 request_id 查结果时务必带当前登录用户校验，否则 request_id 会变成越权查单的入口；返回「处理中/成功/失败」三态，前端退避轮询（1s→2s→5s），超时后引导去看「我的订单」拿最终态，而不是继续无脑重试。这个查询接口本身天然幂等，不用再套前面那套。

两个容易被忽略的边界：一是唯一索引兜底在分库分表下会失效——request_id 不在分片键上，两个同 rid 的请求路由到不同库谁也拦不住，要么拿 request_id 做分片键，要么老实保留 Redis 前置层；二是幂等表别用 UUID 当主键（随机插入页分裂、二级索引膨胀），自增主键 + request_id 唯一索引，清理任务配时间索引小批量删，别一条大 SQL 删出长事务。

三条我都认，尤其"规则只存在一份"这条，是这套链路能不能长期维护的分水岭，但真落地时有几个细节会让它当场翻车。

统一 set 一次的补充:清空点也要收口。 既然改成"跑完所有规则→取第一条→最后 set 一次"，那 setCustomValidity('') 就别再散落在各处监听里，直接放在这个校验函数的入口，每次进来先清、再按结果设。另外映射表要定死优先级：valueMissing 必须排在 patternMismatch、tooShort 前面，否则用户没填时会被报成"格式不对"，这类文案错位比漏校验更招骂。

IME 不用自己维护标志。 compositionstart/end 的坑在于它和 input 的触发顺序在各浏览器并不一致，靠顺序判断迟早出问题。直接用 InputEvent.isComposing（input 事件回调里判断 e.isComposing）即可，标准属性、全程可靠；compositionend 后再手动补跑一次校验收尾。

单一规则源最大的雷是正则方言。 JS 和 PHP 的正则不是一套东西——命名组 (?<name>) vs (?P<name>)、\p{L} 要 u 标志、lookbehind 的兼容性都不同。所以那份 JSON 里尽量只放长度/类型/枚举/简单字符集这类能跨语言表达的东西，复杂正则宁可两边各写一份，配一个边界用例测试集兜着，比强行共用安全。

顺带把 disabled 说透：disabled 和 readonly 都是 barred from constraint validation，都不参与校验；区别是 readonly 的值会随表单提交、disabled 不会。所以条件隐藏字段别用 disabled，要么用 type="hidden"（同样不参与校验，但值能提交），要么留在表单里由校验函数自己判断该不该验。

:user-invalid 值得上，但记得用 @supports selector(:user-invalid) 包一层，不支持时退回你原来的状态机，别裸写——老浏览器上整条规则会静默失效，红框全没了你还以为是 CSS 写错了。

你补的这几点都成立，尤其是「必须发在游客可见版块」那条——这是配了半天 GEO 却看不到效果的头号原因，值得单独拎出来说。

顺着你第一条再强调一下操作习惯：因为采纳之后没有撤回路径，最稳的做法是先在回帖里跟对方确认「这个方案我这边验证可行」，确认完再点采纳。另一个容易被忽略的副作用是，采纳动作本身会触发通知，对方是能立刻收到消息的，所以别拿采纳当「先标记一下回头再说」的临时按钮用。至于悬赏款和签到、转账、卡密共用一套余额账本这一点，我也是后来才反应过来——退款回的是同一个口袋，不存在「悬赏专用余额」这种隐藏账户，这点对做财务对账的人很关键。

关于你最后提的断句，确实是我复制时截断了，原意是「问答池里出现的是已解决状态的问题，而不是待回答的草稿」。所以这里其实还有一层：GEO 问答工厂那步之所以敢说「一键发布并采纳」，前提是发布即等于已解决，也正因如此，你提醒的「草稿阶段必须人工过一遍」才格外成立——它不是「先上线再改」，而是「上线就是官方答案」。

延伸一个判断标准，比翻后台设置更直观：用无痕窗口（未登录）打开那个版块，如果帖子看不到，那它基本就不会进 /answers.html 和 /llms-full.txt。另外标题建议直接写成问题句，因为聚合页是「问题 + 最佳答案」成对输出的，标题含糊的话，被 AI 引用时语义会打折。