为何修改stroke-width后Chrome中的SVG会异常变大？
这个跨浏览器渲染差异的问题，本质是不同SVG引擎在处理极小坐标系统+极小描边宽度时的精度逻辑差异导致的，我来帮你拆解原因和靠谱的解决方法：
为什么会出现这种差异？
你用真实经纬度作为SVG的viewBox坐标，整个视口的范围极小（宽度仅0.00618，高度0.00697），相当于把一个针尖大的地理区域放大到50px的SVG画布上。而你设置的stroke-width是6e-5和7e-5，这个数值已经逼近浏览器渲染引擎的精度阈值了，不同引擎的处理逻辑各不相同：
- Firefox的Gecko引擎对极小数值的精度容错性更好，能正确计算描边和视口的比例，所以两个SVG显示一致；
- Safari的WebKit引擎可能内置了最小描边宽度阈值，6e-5低于这个阈值就被直接忽略了，所以只显示7e-5的版本；
- Chrome的Blink引擎这里踩了数值精度溢出的坑：当描边宽度相对于极小视口的比例超过某个临界值时，引擎的计算逻辑出错，把本应极小的描边错误放大成了覆盖整个SVG的黑色块。
另外要注意：SVG的stroke-width是绝对单位，不会自动跟着viewBox的缩放比例自适应——你可能以为它会像矢量图形一样“智能缩放”，但实际上在这种极端小的视口下，哪怕7e-5的宽度，相对于整个视口宽度已经占到了约1.1%的比例，不同引擎对这个比例的计算精度差异直接导致了渲染结果不同。
统一解决方法
核心思路是避免在极小视口下使用极小的绝对描边宽度，下面是几种可行的方案：
1. 缩放坐标系统（最推荐）
把所有经纬度坐标转换为常规的SVG坐标范围（比如0到50，和你的SVG宽高匹配），这样描边宽度可以用常规数值（比如0.1、0.5），彻底避开极小数值的精度问题。
具体操作步骤：
- 先算出
viewBox的偏移量：minX = -93.146752514，minY = -41.665871084 - 再算出缩放比例：
scaleX = 50 / 0.006181792，scaleY = 50 / 0.006973032 - 把每个坐标点转换为：
(原x - minX) * scaleX，(原y - minY) * scaleY
转换后你的坐标会变成0-50之间的常规数值，描边宽度设为0.1这种正常大小，所有浏览器的渲染效果就完全一致了。
2. 使用vector-effect: non-scaling-stroke（快速应急方案）
如果不想修改大量坐标，可以给<path>添加vector-effect: non-scaling-stroke属性。这个属性会让描边宽度相对于SVG的画布尺寸（也就是你设置的50px宽高）计算，而不是原始的极小经纬度视口，直接规避坐标缩放带来的精度问题。
修改后的path代码示例：
<path d="M -93.144986629000002 -41.665658802999999 L -93.145040273999996 -41.662124163000001 -93.146692513999994 -41.659406928000003 -93.146606684000005 -41.659006146000003 -93.140652180000004 -41.658958052000003 -93.140630721999997 -41.664897388999997 -93.141059874999996 -41.665225999999997 -93.141070604000006 -41.66577101 -93.144932984999997 -41.665811083999998 Z" stroke="black" stroke-width="0.5" fill="none" vector-effect="non-scaling-stroke" />
这里可以把stroke-width改成0.5这种常规数值，因为non-scaling-stroke会让它相对于50px的画布来显示，效果和你原本想要的极小描边一致。
3. 放大viewBox范围
把viewBox的所有数值乘以一个放大系数（比如100000），让坐标变成整数范围，同时保持SVG的宽高为50px。比如修改后的viewBox可以是-9314675.2514 -4166587.1084 618.1792 697.3032，这时候描边宽度可以设置为6、7这种常规数值，浏览器计算时就不会出现精度溢出的问题了。
效果验证
按照上面任意一种方法修改后，你会发现三个浏览器的渲染效果完全统一：Chrome的大黑块问题消失，Safari能正确显示所有描边宽度的版本，Firefox也保持正常显示。
内容的提问来源于stack exchange，提问作者Zachary Blackwood
