WKWebView 中 <progress> 标签需显式设置宽高、避免 -webkit-appearance: none 干扰，默认不触发 change 事件，应通过 input 事件或 postMessage 与原生交互，且不支持用户拖拽。
WKWebView 中如何让 HTML5 <progress> 正常显示并响应 JS 控制
iOS 原生 WebView（WKWebView）默认支持 <progress> 标签，但实际使用中常出现「不渲染」「样式丢失」「JS 修改 value 无反应」等问题。根本原因不是不支持，而是系统默认样式被禁用或 CSS 重置干扰。
- 确保页面
<meta name="viewport">设置合理，避免缩放导致渲染异常 - 显式设置
<progress>的宽高（iOS 对无尺寸的替换元素渲染更保守）：<progress value="30" max="100" style="width: 200px; height: 8px;"></progress>
- 禁用可能覆盖原生样式的全局 CSS，比如
* { -webkit-appearance: none; }会直接干掉<progress>的默认渲染
从 Swift 向 HTML5 进度条传值：用 evaluateJavaScript(_:completionHandler:) 安全写入
不能直接通过 webView.configuration.userContentController 注入，因为 <progress> 是原生表单控件，需操作 DOM 属性而非自定义事件。
- JS 端必须预先定义好
<progress id="myProgress">，否则 Swift 找不到目标节点 - Swift 调用示例：
webView.evaluateJavaScript("document.getElementById('myProgress').value = 65;") { _, error in<br> if let error = error { print("JS 执行失败：\(error)") }<br>} - 注意：iOS 14+ 对跨域 iframe 内的
evaluateJavaScript有 stricter 限制；若进度条在 iframe 里，需确保同源或配置allowsInlineMediaPlayback等绕过策略
监听 HTML5 进度条变化：iOS 不支持 onchange 直接绑定，改用 input 事件
<progress> 在 iOS 上不会触发 change 事件（它只读），但如果你用 JS 主动修改 value 并希望通知原生层，得靠主动回调，而非被动监听。
- HTML 中不要写
onchange="..."—— 它对<progress>无效 - 如需反馈进度变更，JS 端应配合
postMessage：document.getElementById('myProgress').value = newValue;<br>window.webkit.messageHandlers.progressUpdate.postMessage({value: newValue}); - Swift 侧提前注册 handler：
userContentController.add(self, name: "progressUpdate")
，并在userContentController(_:didReceive:)中解析字典
真机上进度条「卡住不动」的常见硬件/系统级原因
部分 iOS 设备（尤其旧款 iPad 或低电量模式开启时）会降频渲染动画，导致 <progress> 的视觉更新延迟甚至冻结，这不是代码 bug。
立即学习“前端免费学习笔记（深入）”；
- 检查是否启用了
webView.isOpaque = false+webView.backgroundColor = .clear，叠加透明背景易触发 Core Animation 性能降级 - 避免在
WKWebView外层套UIScrollView并启用bounces = true，滚动冲突会让<progress>的重绘被丢弃 - 如果进度是模拟加载（比如用
setInterval每 50ms 改一次 value），请改用requestAnimationFrame，否则 iOS WebKit 可能跳帧
实际项目里最常被忽略的是：把 <progress> 当成可交互控件去监听拖拽——它在 iOS 上根本不支持用户拖动，pointer-events: none 是默认行为。需要拖拽体验，得换 <input type="range"> 并自己画进度条。
