Laravel读取MySQL存储的经纬度出现数值精度截断问题

根因排查思路 #

按照从表层到底层的顺序逐层定位问题：

• 排查打印层面的显示假象
  首先确认丢失精度并非实际存储值损坏，而是PHP浮点数打印规则的默认限制：PHP 默认的 precision 配置为14，代表浮点数序列化、打印时仅输出从首个非零数字开始计数的14位有效数字。你示例中的存储值 -32.84240531063937 从首个非零数字3开始计数，前14位有效数字刚好是 -32.842405310639，后面的两位尾数是因为打印配置限制没有显示，并非实际值被截断。验证方式：拿到读取的字段值后，执行number_format($denounced_lat, 16, '.', '')强制按16位小数输出，如果结果和数据库存储值完全一致，就说明实际值没有问题，仅为显示层的截断。
• 排查数据库字段类型的原生缺陷
  你当前使用的无长度参数DOUBLE类型，在MySQL 5.7中等同于64位二进制双精度浮点数，本身仅支持15-17位十进制有效精度，没有强制小数位约束。phpMyAdmin查询时默认会通过二进制转十进制的逻辑，给用户展示最大17位有效数字的还原值，和PDO驱动读取后交给PHP处理的输出规则不一致，就会出现不同客户端看到的数值长度有差异的情况。
• 排查Laravel的自动类型转换逻辑
  Laravel 8默认通过数据库字段元信息做类型映射：检测到DOUBLE字段时，会自动将数据库返回的原始值转为PHP原生浮点类型。这个转换过程不会修改实际数值，但如果后续做数组转字符串、JSON序列化操作时未指定浮点输出精度，就会继承PHP全局的打印规则，表现为数值截断。

合规解决方案（替代临时VARCHAR存储的非优方案） #

1. 全局修正PHP浮点输出精度 #

将项目运行环境的 precision 配置调整为17，这是64位双精度浮点数可准确还原为十进制字符串的最小输出位数。调整后通过dd()、数组转义、JSON序列化输出的浮点数，都会完整展示有效数字，不会出现末尾截断的显示问题。

注意：该配置仅影响浮点数的输出展示规则，不会改动实际存储的数值精度，也不会影响业务计算逻辑。

2. 规范经纬度字段的数据库类型定义 #

替换现有无约束的DOUBLE字段为定点数DECIMAL类型，彻底规避二进制浮点数的转换误差。按照经纬度的常规精度需求（小数点后8位可实现毫米级定位精度），执行以下表结构修改：

ALTER TABLE complaints 
MODIFY COLUMN lat DECIMAL(10,8) NOT NULL COMMENT '纬度',
MODIFY COLUMN lng DECIMAL(11,8) NOT NULL COMMENT '经度';

• 纬度范围为-90~90，整数部分最多2位，设置为DECIMAL(10,8)预留足够的长度冗余（含负号、整数位）+8位小数，可完全覆盖使用场景
• 经度范围为-180~180，整数部分最多3位，设置为DECIMAL(11,8)预留足够的长度冗余+8位小数，无边界值溢出风险
  这种定点数存储会严格按照输入的十进制数值做持久化，不存在二进制到十进制的转换偏差，所有客户端读取到的数值长度完全一致。

3. 补充Laravel模型的类型映射规则 #

DECIMAL类型在PDO驱动返回时默认为字符串格式，为了避免后续业务计算出现类型不匹配，在Complaint模型中补充对应字段的cast规则：

protected $casts = [
    'lat' => 'decimal:8',
    'lng' => 'decimal:8',
];

配置后Laravel会自动将字段值转为固定8位小数的格式，全程不会出现精度丢失。

为什么不推荐用VARCHAR存储经纬度：VARCHAR存储的文本格式无法直接做SQL层面的经纬度范围筛选、距离计算、空间索引优化，每次计算都需要做类型转换，查询性能差且容易出现格式不一致问题，仅能临时规避问题，无法支撑长期业务扩展。

内容的提问来源于stack exchange，提问作者Kataldo