最稳妥方式是用 © 实体直接写，兼容所有浏览器和HTML版本，无需CSS或字体支持；错误做法包括手输©未声明UTF-8、用十进制实体或CSS content直接写UTF-8字符。
页脚显示 © 图标最稳妥的方式是用 © 实体
直接写 © 是最兼容、最不易出错的选择。它在所有浏览器和 HTML 版本（包括 HTML5 和 XHTML）中都原生支持，不需要额外 CSS 或字体加载，也不会因字符编码问题变成问号或方块。
常见错误是手敲 © 符号（U+00A9）并保存为 UTF-8 文件但未声明 <meta charset="UTF-8">，结果在旧环境里乱码；或者复制粘贴时混入不可见的零宽空格，导致渲染异常。
- ✅ 正确写法：
<p>版权所有 © 2024 MySite</p> - ❌ 避免手输 © 后忘记设 charset，尤其在无 BOM 的 UTF-8 文件中
- ❌ 不要用
©十进制写法——虽可用，但可读性差，且部分老旧工具可能解析失败
用 CSS content 插入 © 容易踩编码和继承坑
如果坚持用伪元素（如 ::after）注入版权符号，必须确保生成内容的编码与文档一致，且父元素未禁用 font-family 继承。
典型问题：CSS 里写 content: "©";，但页脚用了 icon font（如 Font Awesome），结果 © 被当成图标码点渲染成齿轮或叉号；或父容器设了 font-family: 'Arial', sans-serif;，而该字体不包含 © 字形，回退失败后显示空白。
- ✅ 安全写法：
content: "\00a9";（十六进制 Unicode 转义，不依赖字体） - ✅ 加上
font-family: initial;强制使用系统默认字体承载符号 - ❌ 避免在
content中直接写 UTF-8 字符，除非确认构建流程全程保持编码纯净
JavaScript 动态插入 © 必须注意 innerHTML 与 textContent 的区别
用 JS 更新页脚时，element.innerHTML = "© 2024" 会触发 HTML 解析，而 element.textContent = "© 2024" 只当纯文本处理。若你传的是 © 字符串，前者能正确转义，后者会原样输出字符串字面量。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
更隐蔽的问题是 SSR（服务端渲染）场景：Node.js 环境下若用 textContent 设置含 © 的字符串，它不会被解析，最终页面里显示的是文字 “©”，而不是 © 符号。
- ✅ 渲染 HTML 片段时用
innerHTML并传入"© 2024"（注意 & 要双写） - ✅ 纯文本插入时用
textContent并传入实际 Unicode 字符"\u00a9 2024" - ❌ 混用：比如
textContent = "© 2024"—— 这只会显示字面量，不是符号
React/Vue 等框架里别忘了 JSX/模板语法的转义规则
在 JSX 中，© 不会被自动解析，必须写成 {String.fromCharCode(169)} 或 {"\u00a9"}；Vue 模板中则支持直接写 ©，但仅限于非绑定属性（如 <p>© 2024</p>），一旦放进 v-text 或 {{ }} 插值，就得用 Unicode 字符或 v-html。
容易忽略的一点：SSR 框架（如 Next.js、Nuxt）在服务端执行时，String.fromCharCode(169) 是安全的，但硬写 \u00a9 字符到 JSX 字符串里，可能因编辑器保存编码或 Git 行尾转换引入损坏。
- ✅ React 推荐：
{'\u00a9'} 2024（ES6 字符串字面量，稳定且无需转义） - ✅ Vue 模板直写：
<p>© 2024</p>（注意 & 要写成 &） - ❌ 在 Vue 的
v-html里传"© 2024"—— 多余且易被二次转义
真正麻烦的从来不是怎么显示 ©，而是它嵌在哪一层上下文里：HTML 解析、CSS 渲染、JS 执行、框架生命周期，每层都有自己的转义逻辑和默认行为。漏掉任意一环，© 就可能变成 、□ 或字面量。
