lang属性须按内容粒度显式标注，不能仅在<html>根节点声明；meta charset必须位于head前1024字节且唯一；white-space:pre-wrap是多语言混排文本的唯一可靠选择；form accept-charset和fetch headers必须显式指定UTF-8。
lang 属性必须按内容粒度显式标注
只在 <html> 根节点写 lang="zh-CN" 不够。浏览器和屏幕阅读器靠每个文本节点的 lang 值决定断行、连字符、字体回退和发音规则。中英混排的段落里夹一句日文，或客服对话中出现阿拉伯语用户名，若没单独标注，white-space 和 text-align 行为可能错乱。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 对非主语言内容块直接加
lang：比如<p lang="en">Hello, world</p>、<span lang="ja">こんにちは</span> - 避免用
lang="cn"或lang="ch"—— 这些不是 BCP 47 合法值，会导致部分 CSS 伪类（如:lang(zh)）失效 - 服务端渲染时，若内容语言动态可变，需确保模板引擎能为每个字段注入对应
lang，而不是统一 fallback 到根节点值
meta charset 必须位于 head 前 1024 字节且唯一
很多老旧浏览器（特别是 Safari 旧版和 IE）在解析 HTML 时，只扫描前 1024 字节来查找 <meta charset="UTF-8">。如果它前面有注释、<script> 或空行超限，就会退回到系统默认编码（如 Windows-1252），导致中文、emoji 显示为 。
实操建议：
立即学习“前端免费学习笔记（深入）”；
-
<meta charset="UTF-8">必须紧接<head>开始，前面不能有任何字符（包括 BOM、空格、注释） - 整个文档只能有一个
<meta charset>；重复声明会被忽略，但可能干扰构建工具或 Linter - 保存文件时选 “UTF-8 without BOM”，尤其在 PHP/Node.js 环境下，BOM 会被当作文本开头输出，破坏 HTTP header
white-space: pre-wrap 是多语言混排文本的唯一可靠选择
API 返回带 \n 的中英日混排日志、评论或错误信息，直接插入 <div> 后文字横向溢出或换行丢失，问题不在字体，而在 CSS 默认的 white-space: normal 会把所有换行符压缩成空格。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 对含原始换行的多语言内容容器，强制设
white-space: pre-wrap—— 它保留\n，又允许在边界处折行，不撑宽容器 - 别用
white-space: pre：禁用折行，长 URL 或无空格英文串直接横向滚动 - 表格单元格（
<td>）要特别注意：Bootstrap 5+ 默认设了white-space: nowrap，必须显式重置 -
text-overflow: ellipsis对pre-wrap无效，写了也不显示省略号，反而掩盖布局问题
form accept-charset 和 fetch headers 必须显式指定 UTF-8
即使页面已声明 UTF-8，表单提交或 AJAX 请求仍可能被某些 Safari 版本降级为 ISO-8859-1 编码，导致后端收到乱码字节。这不是前端 bug，而是浏览器对未明确指定编码的 POST 请求的保守 fallback。
实操建议：
立即学习“前端免费学习笔记（深入）”；
-
<form method="post" accept-charset="UTF-8">——accept-charset不继承<meta charset>，必须手动写 - 用
fetch提交表单数据时，header 中必须包含：Content-Type: application/x-www-form-urlencoded; charset=UTF-8 - 若用
FormData，浏览器自动用 UTF-8 编码，但服务端解析逻辑仍需兼容 multipart boundary 中的 UTF-8 字节
真正麻烦的不是写对一行 lang 或一个 accept-charset，而是这些属性在模板嵌套、CMS 输出、第三方组件注入时容易被覆盖或遗漏。工程维护中，最常失效的恰恰是那些“理论上应该生效”的隐式继承行为。
