SWIFT/BIC校验必须用正则+国家码语义检查，不能仅靠长度；需预处理空格和大小写，封装为可复用验证规则，数据库字段应设VARCHAR(11)，并覆盖null、空串、含空格等边界测试。
SWIFT/BIC字段长度和格式校验必须用正则，不能只靠size或string
SWIFT/BIC不是固定8位或11位那么简单——它有明确的结构规则：4位银行代码 + 2位国家代码 + 2位地点代码 +（可选）3位分行代码。纯长度检查会放过AAAA112233445这种明显非法组合。
-
required|string|regex:/^[A-Z]{4}[A-Z]{2}[A-Z0-9]{2}([A-Z0-9]{3})?$/是基础正则，但注意：国家代码不能是XX，且前两位必须是ISO 3166-1 alpha-2有效国家码（比如USDE合法，QQ非法） - Laravel原生
regex规则不校验语义合法性，真要严格，得配合自定义验证器查国家码表或调用第三方库如php-swift-bic - 别在
rules()里硬写长正则——容易漏转义、难维护，建议抽成SwiftBicRule类或使用Rule::when()动态构造
在Form Request里复用BIC校验逻辑，避免每个控制器重复写
你不会想在UpdateBankDetailsRequest、CreateTransferRequest里各抄一遍正则，尤其当业务要求“仅国际转账需校验BIC，国内走CNAPS不用”时，硬编码规则会迅速失控。
- 新建
app/Rules/SwiftBic.php，实现Illuminate\Contracts\Validation\Rule接口，passes()里做正则+国家码白名单双检 - 在Form Request的
rules()中直接引用：'bic' => ['nullable', new SwiftBic]，比闭包更易测试和复用 - 注意
nullable必须显式声明——BIC字段常为可选，但regex遇到null会直接报错preg_match(): Compilation failed
前端传空格或大小写混杂的BIC，后端要预处理再校验
用户从PDF复制BIC时，常带首尾空格、中间多余空格或小写字母（如deut de ffxxx），Laravel默认不做trim或toupper，直接进正则会失败。
- 在Form Request的
prepareForValidation()里统一处理：$this->merge(['bic' => strtoupper(trim($this->bic))]); - 别依赖JavaScript前端校验——用户禁用JS或用curl直发请求时，后端才是唯一防线
- 如果API允许
DEUTDEFF和DEUTDEFFXXX同时存在，校验逻辑得兼容两种长度，但注意：无分行码的8位BIC默认指向主行，不能当成错误
测试BIC验证边界情况，重点覆盖NULL、空字符串、超长乱码
光测DEUTDEFF通过没用，真实API请求里最常出问题的是这三类值：null、""、"DEUT DE FF XXX"（含空格）、"DEUT123456789"（数字混入）。
- 单元测试里用
$this->postJson('/api/transfers', ['bic' => null])确认返回422且含bic字段错误 - 对
SwiftBic规则单独写dataProvider，覆盖['DEUTDEFF', 'DEUTDEFFXXX', 'DEUTDEFF ', 'deutdeff', 'DEUT12FF']等输入 - 别忽略MySQL字段类型影响：如果数据库列是
VARCHAR(8)却存11位BIC，截断后校验永远通过——实际应设为VARCHAR(11)
真正麻烦的从来不是写对一个正则，而是当财务系统要求“BIC必须匹配银行名录API返回结果”时，校验就得从静态规则升级成HTTP调用+缓存策略——那已经是另一个需要隔离网络IO的上下文了。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
