spellcheck="false"单独加在textarea上在ios safari等移动端无效，必须搭配autocorrect="off"、autocapitalize="none"、inputmode="verbatim"和autocomplete="off"四属性组合使用，且须直接作用于真实textarea节点而非外层容器。
spellcheck="false" 单独加在 <textarea></textarea> 上，只能关掉桌面端 Chrome/Firefox 的下划线，但在 iOS Safari 和部分 Android 键盘上依然会自动纠错、首字母大写、弹拼写建议栏——这不是你漏写了属性，而是浏览器根本不认单这一项。
textarea 必须配齐四件套才真正禁用拼写干预
移动端（尤其 iOS）拼写行为由多个独立机制叠加控制：spellcheck 管下划线，autocorrect 管实时替换，autocapitalize 管首字母，inputmode 管键盘类型。漏一个，就可能被“纠正”：
-
spellcheck="false"：关闭浏览器拼写检查（红线） -
autocorrect="off"：iOS Safari 里这个比spellcheck优先级更高，不加它，recieve还是会被改成receive -
autocapitalize="none"：防止const foo =被变成Const foo = -
inputmode="verbatim"：明确告诉键盘“别联想、别建议、别补全”，这是 Gboard 和 iOS 键盘识别“代码输入”的关键信号
正确写法：<textarea spellcheck="false" autocorrect="off" autocapitalize="none" inputmode="verbatim"></textarea>。Google 翻译页、CodePen 的编辑器都这么用，不是经验之谈，是实测兼容性结论。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
为什么 autocomplete="off" 也得带上
它不直接管拼写，但会影响输入法决策逻辑：
- iOS 键盘看到
autocomplete="on"或没设，会默认开启上下文推测，加大纠错力度 -
autocomplete="off"能抑制基于name属性（如name="code"）的智能联想 - 极端情况下，
autocomplete="new-password"即使不是密码框，也能绕过某些输入法的拼写干预（比如旧版 Samsung Keyboard）
所以完整推荐写法是：<textarea spellcheck="false" autocorrect="off" autocapitalize="none" inputmode="verbatim" autocomplete="off"></textarea>
别给 textarea 外层 div 加 spellcheck
常见错误：把 spellcheck="false" 写在包裹 <textarea></textarea> 的 <div class="editor-wrapper"> 上。浏览器只检查“当前聚焦且可编辑”的元素，外层容器不可编辑，该属性完全被忽略。
<ul>
<li>确认目标节点是真实的 <code><textarea></textarea> 元素本身
contenteditable="true" 的 div 模拟编辑器，那 spellcheck="false" 必须加在这个 div 上，而不是它内部的子节点真正容易被忽略的点是：Safari 在系统「自动拼写更正」开启时，即使四件套齐全，首次聚焦仍可能闪现 200ms 红线——这不是失效，是它的异步词典检查机制。要彻底规避，还得配合系统级设置（iOS 设置→键盘→关“检查拼写”），前端属性只是最后一道防线。
