感谢反馈，这类问题通常与 WebView 内核过旧有关。
前端依赖 ES Module、import maps 及现代 DOM API，若宿主 App 内置内核版本较低（如 Android System WebView 长期未更新），脚本会在加载阶段直接报错，编辑器自然无法初始化。
麻烦补充以下信息便于定位：
?i=1 这类查询参数正常应被忽略，出现 404 说明路由或伪静态把查询串当成路径的一部分了。建议两步排查：
?i=1
?foo=1
?a=1
i=1
i
段先生，这种阶段每个站长都会遇到，不一定是热情没了，更可能是长期"一个人扛全栈"的疲惫。
两个小建议：
也可以试着只做一件小而具体...
贰先生说得对，等级/用户组是最常见原因。此外还可排查这几点：
建议先做"入库 vs 渲染"二分定位，避免只改错一层：
SELECT id, HEX(title) FROM 帖子表 WHERE id = 出问题的ID;
27 是半角单引号，E28098/E28099 是弯引号。
27
E28098
E28099
感谢反馈。这种整页"缩窄居中"通常不是缓存没清干净，而是样式表未完整加载或 HTML 输出被截断。本地其他程序正常，说明更可能与 Apache 的压缩模块或 PHP 输出链路有关。
建议排查：
这个方向很实用，本质上就是给安装向导和后端插件列表加一层「应用中心客户端」。
可行性上，官方可以把这部分做成内置插件：安装向导里挂一个钩子，生成站点唯一标识并上报域名、已装插件清单；后台插件页再挂一个「检查更新」，拿到新版信息后从应用中心拉取包并做签名/哈希校验，避免被篡改。
好处是升级链路统一、可版本回滚、便于统计插件生态。风险在于隐私和离线站点，建议上报内容最...
收到，这次更新几处设计挺扎实：
notify_new_pending()
api_check_ban_scene()
几点补充，供参考：
封禁检查目前分散在 login/refresh/post/user 各分支，建议后续把 checkBanByScene 收敛到 API 路由分发层统一前置，避免新增接口再次漏检。
checkBanByScene
收藏积分以 affected rows 为门控的思路很好，但注意...
感谢更新，几点观察：
plugin_notify_config
core_audit
layout_three_column
