直接使用 rule::regex('/^\d+.\d+.\d+(-[0-9a-za-z.-]+)?$/') 校验 semver 字段，需配合 'required' 和 'string' 规则，确保格式合法且避免类型绕过；不推荐引入第三方包或手动解析。
如何用 Rule::regex() 校验 SemVer 字段
直接在 Laravel 表单验证里校验语义化版本（如 1.2.3、2.0.0-beta.1），别写自定义验证器——Rule::regex() 足够准又轻量。
官方 SemVer 2.0 规范正则较复杂，但实际项目中常用的是「主次修订号 + 可选预发布标识」，推荐用这个兼顾可读与合规：
/^\d+\.\d+\.\d+(-[0-9A-Za-z.-]+)?$/
- 匹配
1.0.0、0.9.12-alpha.3、10.20.30-rc.1+build.123（注意：+ 后的元数据不强制校验，Laravel 验证器不处理 build metadata） - 不匹配
1.2（缺修订号）、v1.2.3（带前缀 v）、1.2.3.4（四段） - 若需支持
v1.2.3，正则开头加v?，但建议 API 层统一约定不带v前缀，避免后续解析歧义
Laravel 10+ 中 validate() 里怎么写验证规则
在控制器或 Request 类里，把 SemVer 字段（比如 version）当字符串校验即可，不需要转成对象或额外解析。
示例（Request 类中）：
public function rules(): array
{
return [
'version' => ['required', 'string', Rule::regex('/^\d+\.\d+\.\d+(-[0-9A-Za-z.-]+)?$/')],
];
}
-
string必须加，否则空值或数字类型会绕过正则（Laravel 会把整数123当作非字符串跳过Rule::regex） - 不要用
nullable+ 正则组合——nullable会让空字符串/ null 直接通过，跳过正则；如需允许空，改用'sometimes|string|regex:...' - 错误提示默认是 "The version format is invalid."，想更明确可自定义：
Rule::regex(...)->message('Version must follow SemVer 2.0 format, e.g. "1.2.3" or "2.0.0-rc.1"')
为什么不用 spatie/semver 或手动 new Version()
引入第三方包或实例化 Version 类做校验，属于过度设计。API 请求体字段校验的核心诉求是「格式合法、快速失败」，不是「解析后做比较或提取字段」。
-
spatie/semver主要解决compare()、isGreaterThan()这类运行时逻辑，验证阶段用不到 - 手动 new Version() 会抛出异常（如
InvalidVersionString），但 Laravel 验证器期望返回布尔结果，捕获异常再转成 false 很别扭，且增加 try/catch 开销 - 正则在校验层足够可靠；真正需要语义解析的地方（比如判断是否为预发布版、计算下一个 minor 版本），放到业务逻辑层再用
spatie/semver更合适
兼容性注意：PHP 版本和 PCRE 引擎差异
这个正则在 PHP 7.4+ 和 Laravel 8+ 环境下完全没问题，但要注意 PCRE 库行为细微差别。
- PHP 8.0+ 默认使用 PCRE2，对 Unicode 和边界处理更严格；旧正则
^[0-9]+\.[0-9]+\.[0-9]+.*$在 PCRE2 下可能误判含 Unicode 字符的预发布串（如1.0.0-α.1），所以坚持用[0-9A-Za-z.-]白名单式写法 - 不要用
\d代替[0-9]——某些 PCRE 配置下\d会匹配全角数字，导致校验松动 - 如果团队用的是 Alpine Linux 容器（musl libc），确保安装了
pcre2而非旧版pcre，否则preg_match()可能静默失败（Laravel 不报错，但正则永远不匹配）
string 类型约束和 v 前缀的统一约定——这两点没卡住，后面所有校验都可能形同虚设。大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
