本文解析PHP通过sqlsrv驱动向SQL Server geography 字段写入点数据时出现“纬度必须在-90到90之间”错误的真实原因，揭示常见误判陷阱，并提供可复用的安全写入方案。
本文解析php通过sqlsrv驱动向sql server `geography` 字段写入点数据时出现“纬度必须在-90到90之间”错误的真实原因，揭示常见误判陷阱，并提供可复用的安全写入方案。
在使用 PHP 的 sqlsrv 扩展操作 SQL Server 的 geography 类型字段时，开发者常遇到一个极具迷惑性的报错：
System.FormatException: 24201: Latitude values must be between -90 and 90 degrees
即使传入的纬度值（如 33）明显合法，错误仍持续发生——这往往不是语法或坐标本身的问题，而是参数绑定顺序与地理坐标的语义约定被隐式颠倒所致。
? 关键事实：SQL Server geography::Point() 的参数顺序是 (latitude, longitude, srid)
注意：先纬度（lat），后经度（lon），这与常见的地理 API（如 Google Maps、GeoJSON）或前端习惯（[lng, lat]）相反。而更隐蔽的风险在于：当使用参数化查询时，若 PHP 数组传入顺序与 SQL 中 ? 占位符位置不严格匹配，极易导致 lat 和 lon 被交换。
例如，以下代码存在高危隐患：
$updateqry = "UPDATE tbladdressorg SET location = geography::Point(?, ?, 4326) WHERE addressid = ?"; $updata = array($acct['shippinglongitude'], $acct['shippinglatitude'], $aborg['addressid']); // ❌ 错误：$updata[0] 是 longitude，但第一个 ? 对应 latitude → 实际执行：Point(long, lat, 4326) $rslt1 = sqlsrv_query($ssconn, $updateqry, $updata);
此时 SQL Server 将 shippinglongitude（如 116.4）误作纬度传入，超出 [-90, 90] 范围，触发 24201 错误——问题不在数值本身，而在参数错位。
✅ 正确写法：显式对齐语义与占位符
务必确保数组元素顺序严格对应 SQL 中 geography::Point(lat, lon, srid) 的声明顺序：
$updateqry = "UPDATE tbladdressorg SET location = geography::Point(?, ?, 4326) WHERE addressid = ?";
$updata = array(
$acct['shippinglatitude'], // ✅ 第一个 ? → latitude
$acct['shippinglongitude'], // ✅ 第二个 ? → longitude
$aborg['addressid'] // ✅ 第三个 ? → addressid
);
$rslt1 = sqlsrv_query($ssconn, $updateqry, $updata);
if ($rslt1 === false) {
die(print_r(sqlsrv_errors(), true));
}⚠️ 额外注意事项
- SRID 必须显式指定：4326（WGS84）是绝大多数场景的标准值，不可省略或动态拼接（避免 SQL 注入）；
- 避免字符串拼接坐标：切勿用 "geography::Point({$lat}, {$lng}, 4326)" 方式构造 SQL——既不安全，也丧失参数化优势；
-
验证输入范围（防御性编程）：
if (!is_numeric($lat) || $lat < -90 || $lat > 90) { throw new InvalidArgumentException("Invalid latitude: {$lat}"); } if (!is_numeric($lng) || $lng < -180 || $lng > 180) { throw new InvalidArgumentException("Invalid longitude: {$lng}"); } - 驱动与连接配置：确认使用的是最新版 Microsoft ODBC Driver（如 v17+）及配套 sqlsrv 扩展（PHP 7.4+ 推荐 ext-pdo_sqlsrv），旧版本可能存在 geography 类型兼容性缺陷。
? 总结
该错误表象是坐标越界，本质是参数绑定逻辑与地理语义的错配。它提醒我们：在涉及空间数据的参数化查询中，不仅要关注数据合法性，更要严守函数签名定义的参数契约。坚持“SQL 占位符顺序 = 数组索引顺序 = 地理语义顺序”，并辅以输入校验，即可彻底规避此类隐蔽陷阱。
