最近在开发中遇到了一个奇怪的问题，如下图（ios系统，android还没找到），第一个和第三个子元素中的角标总是一样的作为父元素是有差距的，但是没有第二个，因为第一次遇到，没有意识到是小数点的问题，后来重新看了相关的样式，布局，以及从头到尾的设置，但是那个差距没有问题。就在那里核心代码：ul{display:flex;证明内容：空格之间；填充：15px；li{位置：相对；宽度：32%；...跨度{位置：绝对；右：0；顶部：0；...}}}坚持实践，得到结果，开始调试（iphone6），把所有布局相关的样式都一个一个改，最后在同事的帮助下，发现把width改成31.5%就可以了，这时候我意识到和css的小数点有关系，于是分析了一下（以下分析仅供参考，浏览器内核是怎么工作的，safari和chrome分别做了什么不清楚）：iphone6的宽度是375px，ul的宽度是345px，所以32%和31.5分别是110.4和108.675。果然，四舍五入后，前者变小，后者变大。网上查了一下，据说浏览器对CSS小数点的处理规则不同，即向下舍入，chrome，safari等向上舍入，参考这两篇文章CSS布局单元，CSS小数点像素问题就明白为什么会这样了之后情况，针对我自己的问题，深层次分析原因，见上面参考链接，webkit内核渲染元素时，真正的渲染区域是固定的，但是文档流中的空间大小是计算出来的，所以直接影响下一个元素，有第二个元素和第一个元素不一样的情况。下图是webkit的计算方法：当width为32%时，按照上面的计算方法，三个元素的结果如下：第一个li,x=15,width=round(15+110.4)-round(15)=110th第二里，x=125.4，width=round(125.4+110.4)-round(125.4)=111第三里，x=235.8，width=round(235.8+110.4)-round(235.8)=110我们可以发现，第一个li，实际渲染区域宽度是110.4，但是文档流中的宽度是110，所以子元素的活动区域是110，那么0.4就是gap中的第二个li，实际渲染区域也是110.4，但是文档流中的宽度是111，第三个计算出来的是110，这就解释了为什么一和三的表达方式一样。宽度为31.5时，宽度为：109、109、109，实际渲染宽度为108.675。测试验证，在ios系统中，safari和in-appwebview的效果与分析一致，但是通过dom获取元素宽度时，与上述计算结果不一致，均为四舍五入的结果，这还不清楚。不过通过分析验证了问题，遇到这种情况有解决办法：合理设置百分比，让计算结果有小数点>=5，四舍五入后的宽度大于实际渲染宽度
