Laravel如何做API请求体字段经纬度校验_Laravel验证数值范围合法性【介绍】

做API请求体里经纬度字段的校验，核心就这几点：between范围要带负号，nullable要配合好；想要更严格的格式校验，自己写个Rule类更靠谱；嵌套和数组字段用点号和通配符；至于小数位数，别在验证层管，交给响应层处理。

验证经纬度字段是否在合法数值范围内

直接用 Lara vel 的 between 规则就能搞定，但必须注意：纬度是 -90 到 90，经度是 -180 到 180，反不得、漏负号更是大忌。很多人写成 between:0,90，结果南纬和西经全被拦在外面，这坑可不小。

• 纬度（latitude）应校验 between:-90,90
• 经度（longitude）应校验 between:-180,180
• 如果字段允许为空，加 nullable，但别加在 between 前面——Lara vel 会跳过后续规则，推荐写成 nullable|between:-90,90
• 前端传字符串（如 "39.9042"）也没问题，Lara vel 验证器会自动 cast 成 float

用自定义 Rule 类做更严格的经纬度格式校验

单纯数值范围够用吗？还不够。比如 999.999 虽然过不了 between:-90,90，但真正要防的是「看起来像数字、实则超精度或非法格式」的输入——带空格、科学计数法、NaN 这些。这时候就得自定义 Rule 了。

• 运行 php artisan make:rule ValidLatitude，在 passes() 里用 is_numeric($value) + 范围判断双保险
• 别用 filter_var($value, FILTER_VALIDATE_FLOAT) —— 它接受 1e2 这种，而地理坐标不用科学计数法
• 示例逻辑：

  return is_numeric($value) && $value >= -90 && $value <= 90;

• 同理建 ValidLongitude，范围换成 -180 到 180

API 请求体里字段名不叫 latitude/longitude 怎么办

实际项目里字段名可能是 lat/lng、coord_x/coord_y，甚至嵌套在 location 数组里。验证规则得跟着结构走，否则 between 直接失效。

• 扁平字段（如 lat）：规则写 'lat' => 'required|between:-90,90'
• 嵌套字段（如 location.lat）：规则键名必须带点，写成 'location.lat' => 'required|between:-90,90'
• 数组字段（如 points.*.lat）：用通配符，'points.*.lat' => 'required|between:-90,90'
• 别在 rules() 方法里硬写死字段名——提取成常量或配置项，换字段时只改一处

为什么不用正则校验经纬度小数位数

有人想用正则限制「最多 6 位小数」，比如 regex:/^-?\d{1,3}(\.\d{1,6})?$/。这看似严谨，其实没必要，还容易出错。

• GPS 设备、地图 API 返回的坐标小数位数不统一，高德可能给 13 位，Leaflet 默认显示 5 位，后端不该卡位数
• PHP 浮点数精度本身有限，floatval("39.90420000000001") 和 39.9042 在比较时可能被当作相等，正则反而制造假性严格
• 真要控制输出精度，放在响应层（number_format() 或 cast），不在验证层
• 唯一需要正则的场景是：字段混入非数字字符（如 "39.9042°N"），那就先用 trim() 和 filter_var(..., FILTER_SANITIZE_NUMBER_FLOAT) 预处理

Lara vel 验证经纬度真正的复杂点不在规则写法，而在字段来源不可控——API 可能被爬虫调、前端可能绕过 JS 校验、第三方系统对接时字段命名五花八门。所以规则得有容错性，验证逻辑要和存储、展示逻辑解耦。