html原生maxlength对contenteditable及codemirror等编辑器无效，因其非表单元素；需js监听input事件手动截断，或用monaco的maxtokenizationlinelength配合变更监听实现单行限制。
为什么 maxlength 在代码编辑器里基本无效
HTML 原生 maxlength 对 <input> 和 <textarea></textarea> 有效，但**不适用于任何基于 contenteditable 或自定义渲染的代码编辑器**（如 CodeMirror、Monaco、Ace、Prism + pre + code）。这些编辑器底层不是表单控件，而是用 div/span 模拟输入，maxlength 属性被完全忽略，浏览器不会拦截、也不会截断。
常见错误现象：给 <div contenteditable="true"> 加 <code>maxlength="80"，毫无反应；给 <pre class="brush:php;toolbar:false;"><code></code> 加也一样——它们根本不是可输入的表单元素。
</pre>
<ul>
<li>
<code>contenteditable 元素需靠 JavaScript 监听 input 事件 + 手动截断
editor.updateOptions({ maxTokenizationLineLength: 80 })），不是 HTML 属性textarea 模拟代码编辑，maxlength 会把换行符 \n 算作 1 字符，导致“单行长度”和实际业务需求错位在 textarea 中模拟单行代码限制的实操要点
若项目简单、无需语法高亮，用 textarea + JS 是最快落地方式。但注意：它限制的是**整个文本域总长度**，要实现“单行最多 N 字符”，必须额外解析换行位置。
- 监听
input事件（不是keydown），确保捕获粘贴、拖入、IME 输入 - 用
value.split('\n')拆出行数组，逐行检查line.length > 80 - 截断逻辑推荐：对超长行用
line.slice(0, 80)，再拼回value，避免正则误删代理对（如 emoji） - 光标位置必须重置：否则用户在第 3 行编辑时，截断后光标可能跳到末尾——需用
setSelectionRange()保持在原行原列 - 移动端测试必做：iOS Safari 对
textarea的换行处理和光标定位有差异，尤其长按粘贴后
Monaco Editor 中控制单行最大字符数的真实配置
Monaco（VS Code 底层）不提供“单行 maxlength”开关，但可通过 maxTokenizationLineLength 和 editorOptions 组合逼近效果——它本质是防止解析器卡死，而非用户输入拦截。
-
maxTokenizationLineLength: 80会让编辑器拒绝 token 化超长行（显示为空白或报错），但用户仍能输入，只是无法高亮/智能提示 - 真正阻断输入，得用
onDidChangeModelContent监听变更，再调用model.applyEdits()回滚超长修改 - 关键细节：Monaco 的
lineNumber从 1 开始，column从 1 开始（不是 0），计算位置时别越界 - 不要依赖
editor.getValue().split('\n')[i].length实时判断——大文件下性能差，应监听event.changes只检查被改的那几行
容易被忽略的边界问题
所谓“单行 80 字符”，在代码场景下远比普通文本复杂。你真正要限制的，往往不是“Unicode 字符数”，而是“视觉宽度”或“打印宽度”。
- TAB 字符（
\t）在不同编辑器中展开为 2/4/8 列，.length返回 1，但实际占位远不止 - 全角 ASCII（如中文引号“”、破折号——）占 2 字符宽度，但
.length === 1 - ANSI 转义序列（如
\x1b[31mred\x1b[0m）不该计入长度，但 JS 字符串里它们就是普通字符 - 服务端校验必须复现前端逻辑：Node.js 用
text.length不够，Python 要用unicodedata归一化 +grapheme-breaker计算真实字形数
最稳妥的做法：前端只做轻量提示（如行尾标红+tooltip），核心长度判定下沉到后端 AST 解析阶段——毕竟一行代码是否“过长”，最终取决于它在 CI/Linter 中是否触发 max-line-length 规则。
