跨浏览器 customevent polyfill 的核心难点在于环境检测、detail 属性手动挂载、原型链对齐（customevent.prototype = event.prototype）、以及 dispatchevent/fireevent 双路径兼容。
解决跨浏览器环境下 CustomEvent Polyfill 的核心实现难点，关键在于准确识别目标环境能力、安全补全缺失构造函数、并确保事件对象行为与原生一致。尤其在安卓旧版自带浏览器、IE9–11等环境中，不能仅靠 new CustomEvent() 简单调用。
判断与降级逻辑必须前置
不能假设 window.CustomEvent 存在或可执行。需在初始化阶段严格检测：
- 先用
typeof window.CustomEvent === 'function'判断是否原生支持 - 若不支持，再检查
document.createEvent是否可用（IE9+ 和部分安卓浏览器依赖此路径） - 若两者皆不可用（极低概率，如极老 Android 2.x WebView），应直接放弃或抛出明确提示，避免静默失败
detail 属性必须显式挂载
原生 CustomEvent 允许通过 detail 传参，但 document.createEvent('Event') 创建的普通 Event 对象默认不含该属性。Polyfill 必须手动赋值：
- 使用
createEvent('CustomEvent')时，initCustomEvent会自动处理detail - 降级到
createEvent('Event')时，需在initEvent后手动添加evt.detail = params.detail - 务必验证
evt.detail可读写，某些安卓浏览器会忽略未声明的属性
原型链与 instanceof 行为要对齐
很多业务代码依赖 event instanceof CustomEvent 做类型判断。Polyfill 若仅覆盖构造函数，不修复原型，该判断在 IE 或旧安卓中会返回 false：
- 正确做法是将自定义构造函数的
prototype指向Event.prototype（如资料中CustomEvent.prototype = window.Event.prototype） - 同时确保构造函数自身有
name属性（CustomEvent.name = 'CustomEvent'），提升调试友好性 - 避免直接修改
window.Event.prototype，仅借用其方法，防止污染全局
触发流程需兼容 dispatchEvent / fireEvent 双路径
构造完事件对象后，分发环节仍有兼容风险：
-
element.dispatchEvent(evt)是现代标准，但 IE8–10 不支持 - IE 需回退到
element.fireEvent('on' + type, evt)，且要求事件对象含button等模拟属性 - 更老环境（如部分安卓 4.0 WebView）可能连
fireEvent都不支持，此时需兜底调用element['on' + type]并手动.call(element)
不复杂但容易忽略
