maxlength 按 Unicode 码点计数，非字节或视觉字符；emoji 和组合字符占多个码点，导致显示字符数与限制不符，需用 Array.from 或 Intl.Segmenter 校验视觉长度，且后端必须独立校验。
maxlength 属性到底按什么单位计数？
它按 Unicode 码点（code point）计数，不是字节，也不是“视觉字符”。这意味着一个 emoji（如 ??）或带组合符的字符（如 é 用 e + ◌́ 表示）可能占多个码点，却只显示为一个字符。
常见错误现象：maxlength="10" 的输入框里，用户粘贴 5 个家庭 emoji（????）就直接被截断——因为这个 emoji 是 7 个码点组成的序列，5 × 7 = 35，远超 10。
实操建议：
- 若需按“用户感知的字符数”限制（比如最多输 10 个笑脸），不能依赖原生
maxlength，得用 JavaScript 配合Array.from(str).length或Intl.Segmenter计算视觉长度 - 后端必须独立校验，前端限制纯属体验优化；
maxlength被绕过太容易（禁用 JS、手动发请求） - 中文、英文、基础拉丁字母基本是 1 码点 = 1 字符，此时
maxlength行为符合直觉
minlength 在表单提交时才生效，且不阻止输入
minlength 不会拦截用户删除字符，也不会在输入过程中报错。它只在调用 checkValidity() 或触发表单提交时参与验证。
常见错误现象：用户输完 2 个字就失焦，没提示；点击提交才看到红色边框和 title 提示（如果设了）；更隐蔽的是，用 fetch 手动提交表单时，若没显式调用 form.reportValidity()，minlength 根本不触发。
实操建议：
- 不要指望
minlength提供实时反馈，需监听input或blur事件，手动检查input.value.length并更新 UI -
minlength对空格敏感：字符串两端空格计入长度，" a "的length是 3；若业务上要忽略首尾空格，得先.trim()再比对 - 与
required组合使用时注意逻辑：空值同时违反required和minlength，但浏览器只报告一个错误（通常是required优先）
中文输入法下 maxlength 的“假性失效”问题
用户用拼音输入法打字时，候选词未上屏前，DOM 中的 input.value 暂时为空或含占位符（如 input 元素内显示“你好”，但 value 还是“niha”）。此时原生 maxlength 无法感知正在编辑的组合状态，导致：用户敲到第 N+1 个拼音字母时被突然截断，或上屏后发现字数超限但已无法补救。
实操建议：
- 监听
compositionstart/compositionend事件，在输入法激活期间临时放宽或暂停maxlength逻辑 - 避免在
input事件中直接截断value（如e.target.value = e.target.value.slice(0, 10)），这会导致输入法上下文丢失、光标跳转异常 - 真正可靠的长度控制，得等
compositionend触发后再检查并截断，且要保留用户光标位置（用setSelectionRange）
textarea 的 maxlength 行为与 input 一致，但换行符计数易被忽略
textarea 中的换行符在不同系统下表现不同：\n（Unix）、\r\n（Windows）、\r（旧 Mac），而 maxlength 统一按码点计——\r\n 算 2 个长度，\n 算 1 个。
常见错误现象：用户在 Windows 上回车一次，长度就 +2；后端按 \n 分割行时发现行数对不上；导出 CSV 时字段意外超长。
实操建议：
- 若需跨平台统一换行行为，提交前将
\r\n和\r归一化为\n，再计算长度或截断 - 显示剩余字数时，别直接用
maxLength - value.length，应先 normalize 换行符再算，否则数字跳变明显 - 服务端接收后仍需再次 normalize 并校验，避免客户端伪造 length
最麻烦的从来不是规则本身，而是用户输入法、操作系统、emoji 版本、甚至浏览器渲染引擎对 Unicode 的实现差异——这些边界情况不会报错，只会悄悄让“最多 10 个字”变成“最多 7 个字还带乱码”。
