maxlength属性才是限制输入字符数的正解，它由浏览器原生拦截键入或粘贴的超长内容并自动截断；size属性仅控制视觉宽度，不约束输入长度，且对响应式布局不可靠，必须配合服务端校验确保安全。
maxlength 属性才是限制输入字符数的正解
size 属性完全不控制能输多少字，只管框看起来有多宽。用户照样能往里粘贴 1000 个字符，然后靠横向滚动查看——这在表单提交时可能直接炸掉后端接口。真正起约束作用的是 maxlength，它由浏览器原生拦截，键入或粘贴超长内容时自动截断。
常见错误现象：给 加了 size 就以为“够用了”，结果测试时一粘贴长文本就出问题。
-
maxlength对text、search、email、password、textarea都有效；对number、date等类型无效 - 计数单位是 UTF-16 code units，中文汉字基本算 1 个，但 emoji（如
"??"）可能占 2–4 个，导致显示截断 - 必须配合服务端校验，否则禁用 JS 或改 DOM 就能绕过
size 属性只影响视觉宽度，且有明显局限
size 是 HTML 层面的简易宽度控制，值为“约等于多少个等宽字符”的显示宽度。它不参与任何逻辑验证，也不响应屏幕缩放，更不和 CSS 协作——加了 style="width: 100%" 后，size 就彻底失效。
容易踩的坑：在响应式页面里写 size="40"，结果在手机上撑破容器；或者用 size="6" 做验证码框，但用户用非等宽字体打开时宽度错乱。
-
size只适用于text、search、tel、email、password等单行输入类型 - 实际像素宽度受字体、字号、浏览器默认样式影响，不可靠
- 现代项目应优先用 CSS 的
width或ch单位替代，例如width: 30ch更贴近“字符宽度”语义
如何让显示宽度和输入限制协同工作
理想状态是：框看起来足够宽，同时用户真没法输超长内容。这时候要明确分工：size 或 CSS 控制“看起来多大”，maxlength 控制“最多输多少”。二者数值不必相等，但建议 size 值 ≤ maxlength，避免用户误以为还能多输几个字。
示例场景：
- 搜索框：
—— 显示宽些方便打字，但上限卡在 50 字防滥用 - 用户名：
—— 固定像素宽 + 明确长度上限 - 评论输入：
——cols类似size，仅外观；maxlength才是命门
遇到 emoji 或生僻字时，maxlength 不够用怎么办
当业务要求“严格按用户感知的字符数（grapheme cluster）限制”，比如评论最多 20 个“人眼可见的字”，就不能只靠 maxlength。因为一个 “??” 在 maxlength="1" 下会被切开成乱码，而用户认为它就是一个字。
这时得补 JavaScript：
- 监听
input事件，用Intl.Segmenter统计真实字符数（Chrome 85+、Safari 15.4+ 支持） - 降级方案：用正则
/\p{Extended_Pictographic}|\p{Emoji_Presentation}/u拆分 emoji，再结合普通字符计数 - 注意：粘贴操作必须单独监听
paste事件并event.preventDefault()后手动处理，否则浏览器原生maxlength可能不生效
最常被忽略的一点：无论前端怎么拦，服务端必须用相同逻辑重验——尤其是涉及数据库字段长度或安全策略时，不能信任何客户端传来的长度声明。
