pattern 属性需用 ^ 和 $ 锚定首尾才能实现全字符串匹配，否则会误判子串；不支持 i 标志，大小写敏感；多单词或复杂规则应改用 JavaScript 配合数组校验，并始终后端二次验证。
pattern 属性能校验输入是否匹配指定单词，但必须用 ^ 和 $ 锚定首尾，否则会误判子串匹配；仅靠 HTML 无法支持“多个可选单词”或“忽略大小写”，这些得靠 JavaScript 补足。
为什么 pattern="admin|user" 不起作用
这个写法会让浏览器尝试匹配字符串中任意位置出现的 admin 或 user，比如输入 administrator 或 superuser 也会通过——因为它们分别包含 admin 和 user 子串。HTML 的 pattern 默认是“部分匹配”，不是“全字符串匹配”。
必须显式加上行首 ^ 和行尾 $：
<input type="text" pattern="^(admin|user)$" title="只能输入 admin 或 user">
-
^强制从开头匹配 -
(admin|user)是一个分组，表示“admin”或“user”二选一 -
$强制到结尾结束，不允许多出任何字符（包括空格）
pattern 不支持 i 标志，大小写敏感是硬伤
HTML 的 pattern 属性不接受正则标志（如 /admin/i 中的 i），所以 pattern="^(admin|user)$" 只接受小写。输入 Admin 或 USER 会被拒绝。
立即学习“前端免费学习笔记（深入）”；
若需忽略大小写，只能放弃纯 HTML 方案，改用 JavaScript：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
const input = document.querySelector('input[data-allowed="admin,user"]');
input.addEventListener('input', () => {
const val = input.value.trim();
if (val && !/^(admin|user)$/i.test(val)) {
input.setCustomValidity('请输入 admin 或 user（不区分大小写）');
} else {
input.setCustomValidity('');
}
});
- 用
setCustomValidity手动控制验证状态 -
/.../i在 JS 中才有效 - 记得
trim()，否则前后空格会导致匹配失败
多个单词、带下划线或数字？别硬塞进 pattern
例如要允许 guest_1、dev2024、test_mode，正则会迅速变得难读且易错：
pattern="^(guest_1|dev2024|test_mode)$"
这种写法维护性差，新增单词就得改 HTML；更糟的是，一旦单词含正则元字符（如 .、+、[），不转义就会崩溃。
推荐做法：把合法值存为数组，JS 动态检查：
const allowed = ['guest_1', 'dev2024', 'test_mode'];
input.addEventListener('blur', () => {
const val = input.value.trim();
if (!allowed.includes(val)) {
input.setCustomValidity(`仅允许: ${allowed.join(', ')}`);
} else {
input.setCustomValidity('');
}
});
- 语义清晰，增删单词只改数组
- 完全规避正则转义问题
- 支持精确字符串比对，无歧义
提交时仍需后端校验，前端只是体验层
无论 pattern 写得多严，用户禁用 JS、绕过表单、用 curl 提交，都能把任意字符串发到后端。所以：
- 前端校验只为提升用户体验，不能替代后端
- 后端必须重新解析请求体，用服务端语言（如 Python 的
in判断或正则）再次确认值是否在白名单内 - 尤其涉及权限关键词（如
admin）时，后端漏校验等于权限绕过
最易被忽略的一点：很多人以为加了 pattern 就安全了，其实它连空格都拦不住——"admin "（末尾带空格）在没 trim() 的 JS 校验里照样能混过去。
