HTML本身无错误边界机制，所谓“HTML错误边界”实为React等框架通过componentDidCatch等生命周期方法实现的JS层容错逻辑，非原生HTML能力。
HTML 本身没有错误边界机制——它不捕获运行时异常，也不提供降级 UI 的能力。所谓“HTML 错误边界”，实际是前端框架（如 React）或 JS 层封装的容错逻辑，不是原生 HTML 标签或属性能解决的问题。
为什么直接在 HTML 中写 errorBoundary 没用
HTML 是静态标记语言，解析失败时浏览器只会尝试容错修正（比如补闭合标签、跳过非法结构），但不会拦截 JS 抛出的错误，也不会阻止白屏或脚本中断。你看到的“错误边界”效果，背后一定是 JS 组件在起作用。
-
<div id="root"></div>这类容器只是挂载点，真正的错误捕获靠的是React.Component的componentDidCatch或useEffect+window.addEventListener('error') - 把
<ErrorBoundary><App /></ErrorBoundary>写进 HTML 文件里，如果不通过 React 渲染器加载，它就只是普通文本，不会执行任何逻辑 - 纯 HTML + 原生 JS 场景下，
try/catch只能捕获同步代码；异步错误（如fetch、定时器、事件回调）需单独监听window.onerror或window.addEventListener('unhandledrejection')
componentDidCatch 在 HTM/React 中怎么配才生效
HTM（htm/react）是基于 React 的轻量模板语法，错误边界必须是标准的 React 类组件，且要确保它包裹了可能出错的子组件——不是加在 HTML 外层，而是嵌在 JS 渲染链路中。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 必须用
class ErrorBoundary extends React.Component定义，函数组件无法使用componentDidCatch -
render()方法里，if (this.state.hasError)分支返回的 UI 才是用户看到的“降级内容”，不能留空或只写return null - HTM 语法中调用要写成
h(ErrorBoundary, null, [h(App)])，不是h('ErrorBoundary', ...)（后者会当 HTML 标签渲染） - 如果子组件用了
useEffect触发异步请求并抛错，componentDidCatch仍能捕获——但前提是该组件被这个ErrorBoundary实例包裹，且没被React.memo或错误的key隔离
原生 HTML 页面如何做最小化错误防护
没有框架时，只能靠 JS 监听 + 服务端 fallback + 人工校验三手准备。重点不是“捕获”，而是“不让用户卡死”。
立即学习“前端免费学习笔记（深入）”；
- 全局监听：在
<script>最顶部加window.onerror = (msg, url, line) => { console.error('JS error:', msg); }，注意它捕不到 Promise reject - Promises 补漏：加
window.addEventListener('unhandledrejection', e => { console.error('Unhandled promise:', e.reason); }) - 关键操作兜底：比如表单提交前用
typeof window.fetch === 'function'判断 API 是否可用，不可用则提示“网络异常，请重试”而非静默失败 - HTML 结构自检：用 W3C Validator（validator.w3.org）跑一遍，
Element div not allowed as child of element p这类报错虽不抛 JS 异常，但会导致后续 JS 获取document.querySelector('p').children返回意外结果——这才是最隐蔽的“错误边界失效”
真正难的不是写一个 componentDidCatch，而是判断哪个组件该被包裹、哪些错误值得降级展示、哪些该直接上报而不干扰用户。很多团队加了错误边界却还是白屏，问题往往出在：包裹范围太小（只包了个按钮）、状态重置逻辑缺失（hasError 一直为 true）、或者降级 UI 本身又触发了新错误。
