“属性泛化”并非 Lara vel 官方概念，实为开发者误用访问器、类型转换或手动截断导致的数据精度丢失；正确做法是数据库用 decimal 存原始值，PHP 用 string 或 BCMath 运算，仅在展示层格式化。
“属性泛化”不是 Lara vel 官方概念，也没有对应 API；所谓“数据精度降低”，本质是开发者误用访问器（accessor）、类型转换（$casts）或手动截断逻辑，导致数值失真——这不是泛化，是 bug。
为什么 getAmountAttribute() 会悄悄改掉你的金额
当你在模型里写：protected function getAmountAttribute($value) { return round($value, 2); }，问题就来了：这个访问器会在每次读取 $model->amount 时强制四舍五入，哪怕原始数据库存的是 123.456，PHP 层拿到的永远是 123.45。更糟的是，它还会污染 toArray()、API JSON 输出、甚至后续计算（比如 $order->amount * 1.08）。
- round() 不是“显示格式化”，而是实时修改值——别把它当
number_format()用 - 如果数据库字段是
decimal(10,3)，但访问器只返回两位小数，等于主动丢精度 - 该访问器对所有调用者无差别生效，包括后台导出、财务对账等需要原始精度的场景
cast 'amount' => 'decimal:10,2' 看似安全，其实埋雷
$casts = ['amount' => 'decimal:10,2'] 确实会让 Eloquent 把数据库值转成 PHP string 或 float，但它不控制入库精度，也不防止你在业务层二次处理时再丢精度。
- 它只影响从数据库读出后的类型转换，不影响写入；如果你
$model->amount = 123.456再sa ve()，MySQL 仍按字段定义（如decimal(10,2)）自动截断为123.45 - PHP 的
float本身有二进制表示误差，123.45可能变成123.45000000000002，尤其在加减运算后明显 - 真正安全的做法是：数据库用
decimal(12,4)存原始值，PHP 层全程用string或BCMath运算，显示层才格式化
想“降精度”只用于展示？别动模型，用资源类或辅助函数
需要把 123.456 显示成 123.46，就该在输出环节做，而不是污染模型状态。
- API 响应走
UserResource：return ['amount' => round($this->amount, 2)];—— 模型原值不动，仅输出变形 - 导出 Excel 或 PDF 时，用独立格式化函数：
formatMoney($user->amount, 2)，内部用bcadd($value, '0', 2)避免浮点误差 - 绝对不要在模型里写
protected $appends = ['amount_rounded']并让它参与所有 toArray() —— 这等于全局污染
精度问题从来不在“怎么泛化”，而在“谁有权决定精度”。数据库字段定义、PHP 运算路径、前端展示，三层必须职责分明。模型不是格式化工具，它是数据契约的守门人——一旦它开始主动改值，你就再也分不清哪一个是真实数据了。
