强制类型转换无法解决float与double的精度截断问题，根本原因是0.1等十进制小数在二进制中本就无限循环，ieee 754浮点表示必然产生舍入误差；真正有效方案是统一使用double、禁用float、几何计算采用bigdecimal（string构造）或robust orient2d等鲁棒算法，并按尺度分层设置容差。
Java中因混用不同精度浮点数（如float与double）并进行强制类型转换，导致几何算法出现拓扑错误（如点在线段上误判为不在线上、多边形自相交检测失效、凸包顶点顺序错乱等），本质是精度坍塌引发的逻辑断言失效。这类错误隐蔽性强，常在边界 case（如共线点、极小夹角、接近重合坐标）中爆发，且难以复现。解决需从数据表示、运算契约、几何鲁棒性三层面协同处理。
统一使用 double 并禁用 float
Java 中 float 仅提供约 7 位十进制有效数字，而典型地理坐标或 CAD 坐标常含 6～8 位小数；float 在缩放、旋转、距离平方计算中极易丢失关键低位比特，直接破坏几何关系判断。
- 项目全局禁用
float类型——尤其禁止float字段存储坐标、长度、角度 - 所有几何类（如
Point2D、LineSegment）成员变量统一声明为double - 禁止隐式或显式强转：
(float) x、someFloatValue * 1.0等操作必须删除或重构
避免跨精度比较与截断
将 double 强转为 float 再转回 double，或对 double 值调用 Math.round(floatValue)，会引入不可逆的舍入抖动，使原本共线的三点因微小偏移被判为三角形，触发错误的面片分裂。
- 禁止任何
double → float → double循环转换；若必须对接 legacyfloatAPI，先用BigDecimal.valueOf(doubleVal).setScale(6, HALF_UP).doubleValue()显式可控截断 - 几何判断（如叉积是否为零、点到线距离是否 ≤ ε）一律基于原始
double计算，不经过中间类型转换 - 避免用
==比较几何中间结果；例如crossProduct == 0.0改为Math.abs(crossProduct) ，其中 <code>EPSILON按场景动态设定（见下表）
采用几何鲁棒谓词（Robust Geometric Predicates）
标准浮点叉积、行列式计算在退化情形（如三点几乎共线）下误差放大，导致符号误判。应使用经误差分析验证的鲁棒实现：
- 对二维点积、叉积、面积符号等基础谓词，使用 Shewchuk 的自适应精度算法（Java 可用 RTree 库内置 robust predicates 或轻量封装）
- 关键判断封装为独立方法，例如：
boolean isCounterClockwise(Point a, Point b, Point c) { return orient2d(a, b, c) > 0; }
其中orient2d返回精确符号，而非近似double - 对坐标做预归一化：若输入坐标范围极大（如经纬度 ×1e7），先平移至原点附近再计算，减少浮点相对误差
设置分层容差（Hierarchical Epsilon）
单一全局 EPSILON 无法兼顾不同尺度几何操作——用 1e-10 判定毫米级 CAD 图元会过严，而用 1e-5 判定地球坐标系下的公里级对象又过松。
| 几何操作类型 | 推荐容差 ε | 说明 |
|---|---|---|
| 点-线距离判定（共线性） | 1e-10 × max(|x|, |y|) | 相对容差，适配坐标量级 |
| 线段相交（分离轴检测） | 1e-12 | 要求高精度，避免虚假相交 |
| 多边形顶点合并（去重） | 1e-9 | 绝对容差，防止过度合并 |
| 凸包稳定性检测 | 使用 robust orient2d，无需 ε | 依赖符号精确性，非距离阈值 |
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
