安企CMS 帮助文档与使用指南
成因写着内置第三方库的核心公告，漏洞不在站方自己写的代码里，却随核心一起分发，因此不能靠改自己的模板或业务代码规避，只能按核心的版本走。跟进时读三段：受影响区间的上下界决定你的版本是否命中，修复版本决定升级到哪一版，评级与利用条件决定排期的先后。以 Drupal 公告 SA-CORE-2026-013 为例，受影响区间跨三个分支，修复分别落在各分支的最新版。
把登录拦截名单写进单个文件，在并发写入下很容易丢条目：两个请求同时读到同一份内容，各自追加后分别写回，后写入的那份覆盖前一份，被拦过的地址就此从名单里消失。没有容量上限的文件会持续增长，读取和解析的时间随之变长；格式不规则的畸形条目会让解析直接出错，导致名单整体失效。名单只是第一层，服务端仍要有独立的校验与验证码环节。
在线升级的数据库脚本必须严格按版本号先后执行，因为每条脚本都以「前一条已经跑完」为前提：新字段还没建起来，后一条往里写值就会失败。跨版本升级时跳过中间版本，表结构会停在半路。脚本执行到一半失败，安全的做法是立刻中止并留下日志，而不是忽略错误继续跑完剩下的脚本，否则问题会被后面的脚本掩盖。升级前先做数据与静态文件备份，升级后逐段核对。
在列表查询里写死索引提示，等于让优化器放弃按统计信息选路径的机会：提示指向的索引与当前条件不匹配时，原本能走覆盖索引或范围扫描的查询会被推到代价更高的执行方式，条件失效时进一步退化成全表扫描。同行程序 PbootCMS 在 V3.2.26 更新记录里就修过列表标签因索引提示退化为全表扫描的问题，并把新装库统一改为按标题字段建索引。
程序保存设置时重写目录级配置文件，会把手工加的规则一起带走，因为这类文件只有一份、由程序按自己的模板整份生成。同行程序 PbootCMS 在 V3.2.26 更新记录里就修过这一问题：Apache 开启伪静态时误判环境导致每次保存都覆盖站点目录下的 Apache 配置文件。划分办法是把程序管理的规则与运维追加的规则分成两处维护，改前备份、改后逐条比对。
带分区属性的登录凭据会按顶层站点分开存储：同一个地址直接被访问时读到一份，被别的站点嵌进页面时读到另一份，两者不共享。官方文档写明该属性表示凭据应使用分区存储，并且设置它就必须同时设置安全标记，还建议用带主机名前缀的名字把凭据绑定到主机而非可注册域。站点若假定登录态全局共享，嵌入场景下就会读不到。
跨域图片的加载耗时在前端监控里读成零，缺的是计时放行响应头。官方文档的定义是：该头指定哪些来源被允许看到通过资源计时接口取到的属性值，否则这些值会因跨域限制被报告为零。取值可以是一个星号放开全部来源，也可以是逗号分隔的来源清单。它只影响计时读数，不改变资源的访问权限，所以补这个头解决的是归因问题，不是访问问题。
用于首屏资源提前加载的 103 中间响应，是服务器还在组织最终页面时先发出的提示，客户端可以提前预连接或预加载资源。官方文档建议出于兼容与安全考虑只在 HTTP 协议 2 或更高版本上发送，多数浏览器也只在这个条件下支持。原因是旧协议下中间响应与最终响应之间的边界处理不一致，容易和等待中的响应内容混淆。
加了安全响应头却在部分响应里看不到，通常卡在两处：一是加头指令只在特定响应码生效，主流 Web 服务器文档列出的生效码包括二百段成功与三百段跳转，非成功响应要靠带 always 参数才无条件添加；二是层级继承规则——同层一旦定义了加头指令，上一层的整组定义就不再继承。排查顺序是先复现缺头的那个响应码，再定位它是哪一层配置生成的。
2026 年 9 月 15 日的一份边缘平台公告把搜索、AI 训练、AI 智能体拆成三项独立控制，站方不必再在保留搜索和挡住训练之间二选一。公告同时给出两个占比：混合用途爬虫占已验证抓取流量的 36.6%，站点侧不到百分之一会挡搜索爬虫、约百分之十七限制 AI 训练。开关拆开之后，放行规则要按访问用途判，而不是按来源域名判。
