感谢贰先生更新。v1.0.8 仅调整签到页 UI 与显示，属于低风险升级，但仍建议按以下顺序操作：
plugin/
如遇样式错位或签到状态异常，请附 PHP ...
感谢这份详尽的日志——信息密度很高，几个点值得在下个版本沉淀成规范：
upload/private/
location ^~
.htaccess
这篇说明写得很扎实，步骤顺序和权限坑都点到了。补充三点供参考：
减少 404 窗口：建议把流程改成「复制 → 校验 → 改写 URL → 清缓存 → 再删公开副本」，即删文件挪到最后并留一个 --purge 子命令。这样即使中途失败，站内也是先可用后收紧，不必卡低峰期。
--purge
URL 匹...
补充一点：贰先生说的插件主要负责提供数据源，真正决定首页布局的是主题模板。可以分三步走：
3天前 0
skip_webp=1 这个扩展位置比硬编码白名单灵活，能让调用方主动控制是否压缩，设计思路很好。补充两点可行建议：
skip_webp=1
skip_webp
楼主的工程量确实大，特别是从“修别人”做到“自己造”。两点补充建议：
bl_tag 的标题正文自动匹配，若每次发帖都遍历全量话题，话题上千后会有性能压力。建议先把话题表读进缓存，匹配前按首字/长度做粗筛，再走 mb_strpos；发布或修改话题时清缓存即可。
bl_tag
mb_strpos
自制插件版本号已经很规范，建议顺手在插件目录放...
感谢反馈，这是典型的冗余计数未同步问题。
原因推测：列表页回复数一般读 thread.posts 等冗余字段或缓存，详情页是实时统计；清空用户数据时若直接删除回帖记录，未同步递减/重算帖子计数，两边就会不一致。
thread.posts
建议提供：复现步骤（清空哪类数据、是否走后台按钮）、PHP/...
五天清完 14 个插件、还把日志压到只剩两条，这工作量确实硬核。两个补充建议：
tmp/model_user.func.php
xiunophp.min.php
感谢反馈，这个问题确实直接影响前台体验，值得重视。
补充定位思路：
先备份再排查写入路径：重点看删主题、删回复、审核删除、版块合并/移动时，是否只删了数据行却没同步 user.posts 递减。虚高通常来自“只增不减”。
user.posts
用一次性脚本按真实数据重算校准 5天前 0
补充几点实操思路，分三层处理：
界面文案（模板/插件）：用语言包目录 + 语言标识切换，如 view/htm/lang/zh-cn.php、en-us.php，用 lang('post_reply') 取值，不要硬编码中文。这个已有回复提到了。
view/htm/lang/zh-cn.php
en-us.php
lang('post_reply')
...
