直接用 includes() 或 indexOf() 判断字符存在性更简单可靠；若必须用正则，应避免全匹配误用，改用 /@/.test(input) 或先行断言 (?=.@)，HTML pattern 属性中需结合字符集约束如 (?=.-)[a-zA-Z0-9_-]+。
校验输入是否包含某个指定字符（如 @ 或 -）
直接用 includes() 或 indexOf() 更简单可靠，但如果你必须用正则表达式——比如嵌在 pattern 属性里或配合 test() 做条件判断——那就得写能“命中存在性”的模式，而不是“全匹配”。常见错误是误用 ^[a-z@]+$ 这类全串约束，它要求整个字符串只能由字母和 @ 组成，不是“包含”。
正确做法是用正向先行断言或简单子串匹配：
-
/@/.test(input)—— 最直白，只要字符串里有@就返回true -
/(?=.*@)/.test(input)—— 正向先行断言，不消耗字符，适合组合多个“必须含”的条件，比如/(?=.*@)(?=.*\d)/表示“必须同时含@和数字” - 避免写
/@+$/或/^@/，它们分别只匹配结尾连续@或开头是@，不是“包含”
HTML pattern 属性中如何表达“必须含某字符”
pattern 属性本质是“整字段匹配”，它默认加了 ^ 和 $。所以不能直接写 /@/，否则会变成“整个输入只能是 @”。必须把“包含”逻辑揉进全匹配结构里。
例如：要求文本框内容**必须含至少一个连字符 -，且只能由字母、数字、下划线和连字符组成，且不能以连字符开头或结尾**：
立即学习“前端免费学习笔记（深入）”；
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 错误写法：
pattern="-"（只接受单个-） - 正确写法：
pattern="[a-zA-Z0-9_]+-[a-zA-Z0-9_]*|[a-zA-Z0-9_]*-[a-zA-Z0-9_]+（覆盖“- 在中间/开头/结尾”三种情况，再用|合并） - 更简洁写法：
pattern="(?=.*-)[a-zA-Z0-9_-]+"—— 先用(?=.*-)确保存在-，再用[a-zA-Z0-9_-]+约束整体字符集
注意：pattern 不支持 g 或 m 标志，只认 i（忽略大小写），所以别加 /.../gi 这种写法。
校验“必须包含多个指定字符”的坑
多个“必须含”条件叠加时，容易写出低效甚至死循环的正则。比如要求“必须含大写字母、小写字母、数字、特殊符号各至少一个”，有人会写 /(?=.*[A-Z])(?=.*[a-z])(?=.*\d)(?=.*[!@#])/ —— 这本身没错，但在 pattern 里会因浏览器实现差异导致部分旧版 Safari 不识别先行断言。
- 兼容性方案：改用 JavaScript 手动
test()，避开pattern的限制 - 性能隐患：每个
(?=.*...)都要从头扫描一遍字符串，10KB 文本+4个断言 = 4万次字符检查；对长输入建议拆成多个includes() - 边界遗漏：
(?=.*\d)不排除字符串全是数字，得额外加字符集约束，如^(?=.*\d)[A-Za-z\d!@#]{8,}$
为什么不用正则也能解决，却常被忽略
绝大多数“是否包含某字符”的场景，根本不需要正则。用原生字符串方法更快、更可读、无兼容风险：
-
input.includes("@")—— 判断是否存在 -
input.indexOf("-") !== -1—— 同上，老环境兼容更好 -
input.split(".").length > 1—— 判断是否含多个点（比/\..*\./直观得多）
正则真正不可替代的，是“位置敏感”的判断，比如“必须以字母开头、含至少一个数字、且数字不能在末尾”。一旦需求退化为单纯“有没有”，就该让位给 includes。
