不是必须，但绝大多数交互逻辑不能用常规JavaScript；AMP运行时会移除非白名单脚本，仅amp-script允许自定义JS（需SRI校验），且原生img须换为amp-img（默认懒加载、强制宽高）。
AMP 页面必须用 amp-script 替代普通 JavaScript 吗？
不是必须，但绝大多数交互逻辑不能用常规 <script></script>。AMP 运行时会直接移除或阻断非白名单脚本，包括内联 onclick、document.write、fetch（除非通过 amp-bind 或 amp-list）等。真正可用的 JS 仅限于 AMP 自己封装的组件行为，比如 amp-carousel 切换、amp-accordion 展开——这些背后是 AMP 运行时控制的，开发者不写原生 JS。
-
amp-script是唯一允许运行自定义 JS 的组件，但受严格限制：只能在src指向的外部文件中加载，且该文件需满足 Subresource Integrity（SRI）校验 - 本地
inline脚本即使加了data-ampdevmode也不会执行（开发模式下仅跳过部分验证，不解除执行限制） - 常见报错如
"Script execution is disabled in AMP documents"就是触发了这个拦截
图片懒加载不写 loading="lazy" 会拖慢首屏吗？
在 AMP 页面里，这个问题其实不成立——因为 AMP 强制所有 img 必须用 amp-img，而 amp-img 默认就内置懒加载和尺寸校验，不需要、也不支持写 loading="lazy"。如果你手动写了原生 "The attribute 'loading' may not appear in tag 'img'."
-
amp-img的懒加载时机由 AMP 运行时统一管理，基于视口距离 + 网络状况（如saveData开启时延迟加载非关键图） - 替换原生
img时，必须补全width和height属性，否则 AMP 验证失败，页面无法通过 CDN 缓存分发 - 如果用了
amp-lightbox或amp-image-lightbox，里面的图是按需加载的，不参与首屏渲染计算
AMP Cache 加速失效的常见原因有哪些？
AMP Cache 不是自动生效的，它只缓存通过 AMP 验证且符合协议要求的页面。以下情况会导致缓存失败或降级为普通 HTTP 回源：
- 页面包含未签名的
amp-script或使用了amp-bind但没加data-amp-bind属性（验证器报"Missing mandatory attribute: data-amp-bind"） -
canonicallink 指向的非 AMP 页面返回了 4xx/5xx 状态码，或响应头含Cache-Control: no-store - 使用了非 HTTPS 的资源（如
@#@#@#@#@#@#@#@#@#@0），AMP Cache 会拒绝抓取并记录"Mixed Content blocked" - 自定义字体通过
@import引入而非amp-font组件，部分 CDN 节点可能跳过缓存预热
为什么开了 AMP 还被 Google Search Console 标为“移动速度不合格”？
AMP 页面本身不等于“快”，它只是提供了一套约束性框架。Search Console 的“移动速度”评分来自真实用户数据（CrUX），而 AMP 页面若存在以下问题，照样拉低 LCP、INP 或 CLS：
-
amp-list渲染大量列表项但没设max-items，导致首次渲染卡顿 -
amp-video或amp-iframe自动播放且未加muted，触发浏览器静音策略后反复重试加载 - 第三方广告标签（如
amp-ad）配置了多个备用网络，但 fallback 链路过长，某一个超时就会拖慢整体资源调度 - 使用了
amp-bind+ 复杂表达式（如嵌套三元、多次map），在低端安卓机上引发 INP 延迟突增
AMP 对移动加速不是“开关式优化”，它把性能责任从运行时转移到构建和验证阶段。最容易被忽略的一点是：AMP 页面一旦上线，其 HTML 结构就几乎不可动态变更——所有条件渲染、A/B 实验、个性化内容都得提前静态化或通过 AMP 支持的异步组件兜底，否则反而引入额外延迟。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
