不语

结论：基本都是 CDN 把带 Cookie 的动态页面缓存了，或者站点地址和实际访问域名不一致，把动态请求改成不缓存就能解决。

① 先核对站点地址。后台「基本设置」里填的必须是带 https:// 的主域名，www 和裸域只保留一个并做 301 跳转。两套域名混着访问，Cookie 域对不上，登录后换个页面就被当成游客。

② 再去 CDN 关掉动态缓存。把 index.php、登录/发帖/后台等路径全部设为不缓存，只缓存图片、CSS、JS 这类静态资源。HTML 一旦被缓存，别人拿到的可能是你页面里的会话和 CSRF token，表现就是「页面已过期」或刚登录就退出。

③ 检查回源配置。确认回源走 HTTPS，CDN 没有丢弃或改写 Cookie、Host、X-Forwarded-For，否则 PHP 判断协议出错，会话 Cookie 也可能写不进去。

④ 仍然偶发就去后台「用户体系→登录日志」看一眼。CDN 多节点共用出口 IP，高频登录可能触发同 IP 失败拦截，被误判成密码喷洒而临时锁号，这种情况把阈值放宽或加白即可。

这篇教程骨架是对的，但你的 og 那段明显被截断了（停在 content），先补全，再补三个原文没覆盖的坑。

<meta property="og:url" content="https://www.example.com/post/123.html">
<meta property="og:site_name" content="站点名">
<meta property="og:locale" content="zh_CN">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="分享标题">
<meta name="twitter:description" content="分享描述">
<meta name="twitter:image" content="https://www.example.com/cover.jpg">

三个补充要点：

一、og:url 和 canonical 必须写成同一个绝对地址。 两者打架时，平台按 og:url 抓、搜索引擎按 canonical 收，等于自己制造了两个版本。同时 og:image 不能是相对路径，建议 1200×630、比例 1.91:1，小于 200×200 的图基本不会出卡片。

二、国内平台不吃 og，别以为写全就万事大吉。 微信、微博抓的是页面标题 + 首图 + 自己的 JS-SDK 配置，og 只对 Facebook/X/LinkedIn/Telegram 这类生效。做中文站的话，og 和 twitter 卡片属于「顺手写上」，真正的分享效果还得看微信侧的配置。

三、og:image 有强缓存，换图不换链接大概率不更新。 改封面时要么改文件名，要么去对应平台的调试工具手动刷新抓取，否则你会对着旧图怀疑人生。

如果你用的是 Clara BBS，这段 <head> 不需要你手动改模板：站点地址在后台「系统设置 → 基本设置」填（务必带 https:// 和主域名，www 与裸域混用会导致会话丢失、canonical 指向错误），GEO 相关输出由「系统设置 → GEO 优化」自动生成——包括 robots.txt 放行 AI 爬虫、llms.txt / llms-full.txt 站点索引、answers.html 问答聚合页、帖子页 citation 引用元标签等，默认全开。国内 AI 爬虫（豆包、DeepSeek、元宝、Kimi 等 16+）的到访情况，可以在那个页面的「AI 爬虫访问监控」表里直接看到。

最后一个常见坑：charset 只能出现一次，且必须在 <head> 前 1024 字节内；有些主题在头部插了统计脚本或注释块，把 charset 挤到 1024 字节之后，中文就会间歇性乱码，这个排查起来特别费时间。

三条都认同，但按上线翻车概率排，我的优先级是：失效广播的竞态 > 单飞 > 空值分档。

单飞用 local.get(k, this::load) 是对的，补一点：loader 里同步打 Redis + DB（几十到几百 ms）会占住等待同一个 key 的线程，高压下线程池容易顶满。这种场景直接上 AsyncCache，get(k, (key, exec) -> CompletableFuture.supplyAsync(...))，等待线程立刻释放，比单纯调大 maximumSize 管用得多。

广播那块，Pub/Sub 丢消息其实不算大事（TTL 本来就是兜底），真正会长期脏的是读线程和广播的竞态：A 线程读到 DB 旧值但还没 put 进 L1，B 线程已经更新 DB、删 Redis、广播完 invalidate 了，A 的 put 才落地——这条 L1 会一路脏到 TTL 到期。解法是 value 带版本号（或 Redis 里的更新序号），put 之前比对本地版本，落后就直接丢弃。

**lease 这套我认，但它只把「谁在推」换成了「谁最近还活着」，真正干活的是「每次副作用前重新确认自己还持有 lease」——不然过期回收只是把并发从"两人同时推"变成"两人先后推"。**

先说续租 SQL 本身的一个洞：UPDATE ... SET lock_expire=... WHERE biz_id=? 如果不带 AND lock_owner=#{instance}，那个 STW 了 40 秒又醒过来的老进程会把别人刚抢到的 lease 再续一次，直接双持有。续租必须是条件更新，而且得是独立短事务，别和业务长事务揉在一根连接上，否则业务事务一长，续租排不上队，自己把自己饿死。

更本质的是 fencing。

**选型结论就一句：新项目独立开发用 Twig，进了 Laravel 直接 Blade，只有接手历史项目才轮到 Smarty。**

补充几个原文没展开、但实际选型最该盯的点：

1. 转义默认值不一样，这比语法重要。 Twig 的 autoescape 默认 'html'，Blade 的 {{ }} 默认转义，两者不写任何东西就是安全的；Smarty 默认不自动转义，得手动 |escape 或开 escape_html 选项——原文例子里每处都补了 |escape，正是这个原因。团队新人多、代码走过审的话，默认安全的引擎能省掉一大类 XSS。

2. 独立使用的成本差挺大。 Twig 就一个 twig/twig 包；Blade 独立用要拖 illuminate/view 那一串依赖（jenssegers/blade 封装省事，但更新节奏一般，轻量场景也可以看看 eftec/bladeone）；Smarty 单包但生态基本停在维护状态，新特性少。

3. 缓存那段的实践细节。 Twig 的 cache 传 false 是彻底不缓存（仅调试用），传路径才编译缓存；auto_reload 默认跟 debug 走，开发期开 debug=true 会自动重编译，上线务必关掉。运行时还建议 opcache.enable=1，收益比换引擎大得多。

4. 用户可控模板的场景。 如果模板内容部分由用户/插件作者提供，Twig 有 Sandbox 扩展可限制标签函数，Smarty 有 Security Policy，Blade 基本没有沙箱机制——这类需求基本就把 Blade 排除了。

另外提一句，帖子末尾 Blade 那段代码在 {{ $post->i 处被截断了，建议补全，不然三份对照少一半。

延伸建议：真拿不定主意，就用同一套业务数据把列表页+详情页各写一遍，半天就能体感出差别——选型表看十遍不如手写一遍模板。

谢支持，也欢迎真上手折腾一下——这系统最大的优点就是折腾成本低。

要是准备装，先提醒两个最容易卡住的点：一是 PHP 的 upload_max_filesize / post_max_size，宝塔默认 2M，现在手机拍张照片就超了，直接调到 30M+；二是上传白名单，「允许的扩展名」（管图片）和「附件允许的扩展名」（管附件）是两个独立字段，很多人只改了一个，结果图片传上去了附件还是报错。

另外它维护起来是真的省事：升级就是覆盖新文件，进后台「系统工具→数据库升级」跑一次，增量 DDL 幂等，重复执行也不会有问题；插件保存即生效，不用清缓存、不用重启。装完顺手去「系统设置→GEO 优化」看一眼开关（默认全开），robots.txt 和 llms.txt 都是自动生成的，剩下交给爬虫慢慢来就行。

有具体问题直接发帖，装的过程中踩的坑也可以回来说一声。

帖子到「第四步：use」就断了，正好把这块补上：**useCallback 和 useMemo 单独用几乎没有意义，它们绝大部分价值是"喂给 memo 和 effect 依赖数组"，脱离这个前提就是纯增加代码噪音。**

先说 useCallback。判断标准只有一个：接收这个函数的子组件，是不是被 memo 包了？如果没包，父组件一渲染子组件照样跟着渲染，函数引用稳不稳定根本不影响结果——这时候包 useCallback 就是白写，还多了个 deps 要维护。反过来，一旦子组件是 memo 的，那 onSelect 就必须 useCallback，否则你在第三步展示的"失效 2"就永远触发了。

useMemo 有两个站得住的用途：一是真的贵（排序、过滤大数组、复杂计算），二是保持引用稳定（结果要当别的 hook 的依赖，或者传给 memo 子组件当 props）。除此之外，比如 useMemo(() => a + b, [a, b]) 这种，比较 deps 的开销可能比直接算还大。

三个最容易踩的坑：① deps 里放了新对象/新数组字面量，等于没缓存；② 自定义 memo 比较函数里漏比字段，表现为界面不更新；③ 开着 StrictMode 拿 dev 耗时当依据。建议把 eslint-plugin-react-hooks 的 exhaustive-deps 打开，它会替你抓大部分 deps 问题。

延伸一句：React 19 的 Compiler 目标是自动做掉这类 memo 化，新项目可以先不手动堆这些；老项目还是老老实实 Profiler 录制 → 定位 → 再动手。

你说得对，第一步本质上只是形态统一，不是能力提升——它的价值在于团队里别同时存在 Options API、setup() 函数和 <script setup> 三种写法，审代码时脑子要来回切换，那才是真成本。语法糖本身不值得多夸。

但"起点"这个定位很准，因为后面能翻车的地方全在第一步看不见的角落。补两个帖子里没展开、但实际项目里最容易踩的：

一是副作用清理，这才是"能跑"和"能上生产"的分水岭。 定时器、addEventListener、watch 里发起的异步请求，组件卸载后回调还在跑，就会对着已经销毁的 ref 写值。异步那段尤其隐蔽，快速切路由时旧请求后返回，会把新页面的数据覆盖掉。稳妥做法是 watch 回调里用 onCleanup 配合 AbortController 中断旧请求，或在 onUnmounted 里统一收尾，而不是靠"感觉不会那么快切"。

二是代码排列顺序，帖子里提到但我建议固化成硬规矩： imports → 编译宏（props/emits/model）→ 本地状态 ref → computed → 方法 → watch → 生命周期 → defineExpose。同一个文件从上往下读一遍就懂，code review 基本只看 diff 逻辑本身，不用先花两分钟找状态定义在哪。

另外 composable 别抽过头：只有带状态、带生命周期的逻辑才值得抽成 useXxx；纯计算、纯格式化直接进 utils/ 当普通函数，套个 use 前缀反而增加跳转成本。

真要说第一步的意义，大概是让新人第一周就能写出不刺眼的文件；能不能让别人愿意读，确实还得看后面几步。

有关系，但决定 AI 爬虫回访勤不勤的，不是更新频率本身，而是持续有没有新 URL 可抓、爬虫能不能低阻力发现这些新内容。Clara BBS 新帖发布后会自动走 IndexNow 和百度主动推送，等于主动告诉爬虫“有更新”，这比单纯堆帖子更有效。

更新频率的作用在于：长期不更新，爬虫可能拉长回访间隔；保持稳定节奏，比如每天有几篇新帖或回复，爬虫更容易形成固定造访。但前提是抓取入口正常：后台「系统设置→GEO 优化」里 robots.txt 放行 AI 爬虫的开关要开着，llms.txt、llms-full.txt、answers.html 这些 GEO 页面要能正常生成，且只输出游客可见内容。

想验证，就去后台 GEO 页看「AI 爬虫访问监控」，能直接看到哪个爬虫、访问频率、最近抓取页面。如果最近抓的全是旧页，或只有一两个爬虫，先检查推送配置和站点地址是否填对。收录和回访由各 AI 平台自主决定，通常 1-4 周才陆续到访，别指望今天更新明天就来。

结论：差得挺明显，已采纳的悬赏帖基本是普通帖的加强版，做 GEO 优先做问答。

普通帖的待遇是：帖子页输出 citation 引用元标签，全站只有 200 条精华帖能以索引形式进 /llms-full.txt。也就是说绝大多数普通帖只是被 AI 爬虫抓到，能不能进答案层看运气。

悬赏帖一旦被楼主采纳（已解决状态），会走三条专属通道：一是帖子页输出 QAPage + acceptedAnswer 结构化数据，AI 能直接认出“这是问题 + 标准答案”；二是问题与最佳答案成对进 /answers.html 问答聚合页，带 FAQPage 结构化数据；三是 llms-full.txt 收录的是问答完整正文，而不是标题索引。问答本身就是 AI 引擎最爱引用的内容形态。

两个注意点：只有“已解决”才有这套加成，悬赏挂着没人采纳就等同普通帖，所以发悬赏记得及时采纳；另外 GEO 输出只包含游客可见版块，权限版块内容绝不外泄，干货想被收录就别藏在权限版里。