开启JavaScript延迟、合并或压缩后，菜单、轮播或结账失灵，应先撤回最近一项优化做对照，再定位依赖顺序和触发条件。测速分数提高不能替代功能正常。
不同优化不是同一件事
压缩主要减少代码体积，合并改变文件组织，defer与async影响执行时机，延迟执行则可能等到用户交互后才运行。插件界面把它们放在一起，不代表可以同时开启而不用测试。
脚本A依赖脚本B时，如果优化改变执行顺序，A可能先运行并报未定义错误。依赖页面初始化事件的代码，也可能因过晚执行而错过时机。
用最小变化找出触发项
保存现有优化设置，在测试环境仅关闭最近启用的一个选项，清理对应缓存，再重复相同操作。若恢复正常，继续缩小到具体脚本或页面类型。
观察Console最早的错误，以及Network中资源加载次序。记录受影响文件、依赖库和操作，不要仅凭文件名中有jquery就排除所有脚本。
排除规则应尽量具体
根据插件官方支持的方式排除必要资源或页面。某些功能需要同时保留依赖库和调用脚本的正确顺序，仅排除其中一个仍可能失败。
购物车、结账、登录、表单和同意管理等交互应特别验证。不要把所有脚本都排除后仍宣称优化已完成；应记录实际保留了哪些优化、哪些因兼容性关闭。
验证要覆盖首次交互
清除浏览器缓存，以未登录访客身份首次打开页面，不先随意点击其他位置，再操作目标按钮。某些延迟机制会在第一次点击后才加载脚本，第二次测试正常可能掩盖首次点击失效。
检查桌面和手机、直接进入内页及从首页跳转的路径。对关键表单验证保存结果，对商城使用受控测试核对订单，不能只看按钮有动画。
是否应始终合并JS？ 不应机械开启。实际收益取决于协议、缓存、文件数量与实现方式。以真实加载表现和功能完整性为准，不以开关数量判断优化水平。
参考资料
相关问题
本文为通用排查指南，依据所列官方资料整理；菜单名称和行为可能随版本及主机环境变化。配图为AI生成的概念示意，不是实际故障截图。
