端口号正则不能直接写 ^[0-9]{1,5}$，因其无法排除前导零（如08080）、超限值（如65536）及非法范围（如0），合法端口应为1–65535且无前导零，推荐分段正则校验。
端口号正则为什么不能直接写 ^[0-9]{1,5}$
这个表达式看似能匹配 1~5 位数字，但会放过 0、00、65536、99999 这类非法值。端口号合法范围是 0–65535，其中 0 虽在协议中保留，但多数 Web 场景（如 fetch、XMLHttpRequest、浏览器地址栏）实际只接受 1–65535，且不允许前导零。
常见错误现象：
用户输入 08080 被当成合法（其实应拒绝），或 65536 没被拦截（超出 uint16 上限）。
- 必须排除前导零：用
^[1-9][0-9]{0,3}$匹配 1~4 位非零开头的数，再单独处理65535和10000–65535区间 - 更稳妥的做法是分段：1 位（
1-9）、2 位（10-99）、3 位（100-999）、4 位（1000-9999）、5 位（10000-65535） - 最终推荐正则：
^(?:[1-9][0-9]{0,3}|6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|6[0-4][0-9]{3}|[1-5][0-9]{4})$
HTML input 的 pattern 属性怎么用
直接在 <input> 上加 pattern 可触发浏览器原生校验，但注意它只在表单提交或调用 checkValidity() 时生效，不监听实时输入。
使用场景：
适用于简单表单，比如配置代理地址、填写 WebSocket 端口等轻量交互。
立即学习“前端免费学习笔记（深入）”；
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 必须搭配
title属性，否则出错时提示为空白 - 正则开头结尾**不要加**
/，HTML 的pattern是纯字符串，不是 JS 正则字面量 - 示例：
<input type="text" pattern="^(?:[1-9][0-9]{0,3}|6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|6[0-4][0-9]{3}|[1-5][0-9]{4})$" title="请输入 1–65535 之间的有效端口号"> - 若允许
0（极少见），把开头改成^(?:0|[1-9]...)，但需确认后端和协议是否真支持
JavaScript 中用 test() 校验更可控
浏览器 pattern 不够灵活，比如要高亮错误、动态禁用按钮、或和 IP 地址联动校验时，就得用 JS 手动判断。
性能影响很小，正则本身是 O(1)，但要注意全局标志 g 会导致 lastIndex 状态残留，引发偶发失败。
- 定义正则时**不要加**
g标志：const portRegex = /^(?:[1-9][0-9]{0,3}|6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|6[0-4][0-9]{3}|[1-5][0-9]{4})$/; - 调用：
portRegex.test(inputValue)—— 注意传入的是字符串，number类型需先toString() - 如果已知输入是数字，更推荐直接数值判断：
!isNaN(port) && port >= 1 && port ，语义清晰且无正则陷阱
为什么建议「数值判断优先于正则」
端口号本质是整数，正则只是字符串层面的模拟。真实项目里，你大概率会从 input.value 取值，然后转成 Number 发给后端或用于 new WebSocket()，这时候绕一圈正则反而多一层转换风险。
容易被忽略的地方：parseInt("08080", 10) 得到 8080，但用户本意可能是想输八进制（虽然不合理），而正则若没禁前导零就会漏掉这个歧义；反过来，数值判断天然过滤掉所有非数字字符和前导零。
- 输入框可加
inputmode="numeric"和pattern="[0-9]*"（仅限制键盘输入，不影响语义） - 真正校验逻辑放在提交前：
const port = Number(input.value); if (port 65535 || !Number.isInteger(port)) { /* 报错 */ } - 正则只作为辅助（比如 placeholder 提示格式），别让它成为唯一校验手段
