默认模板跟着前端框架升了一个大版本，站里的样式和脚本要跟着改哪些

默认模板跟着前端框架升了一个大版本，站里的样式和脚本要跟着改哪些？改动不会只停在版本号上。PbootCMS 公开的更新记录里能看到两处典型动作：前台默认模板的样式框架 Bootstrap 升级到 5.3.8，同时移除 Popper 与 datetimepicker 两个依赖；后台与前台的 jQuery 从 1.12.4 升到 3.7.1，并额外修正了内容状态复选框在界面组件库下的显示。对已经改过模板的站点来说，这三处正是回归要覆盖的范围。

第一处是类名与组件结构

大版本升级最常见的破坏点是命名与结构：框架把一批类名换掉、把某些组件的必需嵌套层级改掉，样式就会以「局部错位」的形式出现，而不是整页崩坏。升级后要逐项打开的页面包括列表页、详情页、表单页与分页控件，其中表单和分页最容易因结构变化而错位。

判断依据不是页面看起来还行，而是自定义样式里那些以框架类名为选择器的规则是否还能命中。自建主题里如果有直接依赖旧类名的写法，这一步应当先改选择器，再谈视觉微调。

第二处是被移除的依赖库

移除依赖是升级记录里信息量最大的一行。以日期选择控件为例，旧写法通常是引入一个独立插件加一段初始化代码；框架大版本自带原生控件后，这两处都要跟着改，否则页面上会出现「控件不弹」或「弹两层」两种表现。级联选择、下拉与模态框这类需要定位支持的组件同理，依赖关系已经合并后，原来的引入顺序反而会成为冲突源。

对应到站内的动作是：搜出所有引用被移除库的位置，逐个确认改用框架原生能力还是自己补一个控件。这一步不要省略搜索，模板里的引用经常散落在个别页面。

第三处是脚本库跨版本的行为差异

脚本库跨大版本升级带来的不是接口新增，而是旧写法失效。移除的通常是已经废弃的分支写法与事件绑定形式，自定义脚本里如果有这类用法，页面表现是「部分交互失灵」。更新记录里同时修了一个界面组件下复选框的显示，说明即便主功能没问题，组件层面的样式差异也要单独核对。

值得注意的还有升级理由里那句「修复旧版安全漏洞」。脚本库跨版本升级同时是一项安全维护动作，把它归到「样式改动」里推迟，会让旧版本继续留在站上前台。

自定义模板怎么承接这类升级

改过默认模板的站点，直接覆盖更新会丢自己的改动，正确顺序是三步：先把当前模板与静态资源做一次备份，AnQiCMS 的备份能力支持数据连同静态文件一起带走；再对比新旧模板的差异，把改动按「类名替换、依赖移除、初始化重写」三类分开列出；最后用可视化模板编辑逐页确认改动能落到站点里生效。

回归清单建议按控件而不是按页面写：一个页面里可能同时涉及级联、日期与复选框三类控件，按控件走一遍更不容易漏。全部通过后再更新前台资源缓存，避免旧样式文件继续命中。

常见问题

问：只改了标题和配色，也要跟着模板大版本回归吗？ 答：要。改动少不代表引用的组件少，标题区里的日期、下拉与轮播脚本都会受框架版本影响。

问：能不能只升样式不升脚本库？ 答：可以短期分开，但脚本库跨版本通常同时带有安全修复，长期停留在旧版本会让风险留在前台页面上。

问：改完之后表现时好时坏，先查什么？ 答：先查是否有旧依赖与新框架同时被引入，再查静态资源缓存是否还命中旧文件，这两类问题都会表现为随机失灵。