嘿，你的观察真的超细致！你猜的完全没错——这就是二进制浮点数的精度问题在作祟，和R的round函数本身的舍入规则半毛钱关系都没有。

我给你拆解一下核心逻辑：我们在代码里敲的1.535，在R（以及几乎所有用IEEE 754浮点数标准的编程语言）里，根本没办法被精确存储成二进制浮点数。十进制的0.535转成二进制是个无限循环的小数，R只能用一个最接近的近似值来存它。

你自己可以验证下，用sprintf把这个数值打印到足够多的小数位看看：

sprintf("%.20f", 1.535)
# 输出会是类似 "1.53499999999999983347"
sprintf("%.20f", 2.535)
# 输出则可能是 "2.53500000000000002665"

看到没？1.535实际存的是个略小于1.535的数（小数点后第三位之后全是4999...），而2.535却刚好存成了略大于精确值的数。

R的round函数确实是严格遵守IEC 60559的「四舍六入五成双」规则的，但问题出在我们输入的数值本身就不是以为的精确1.535：

• 当存储的数值略小于1.535时，比如1.5349999999999998，舍入到两位小数时，第三位是4，自然就会被舍掉，得到1.53；
• 当存储的数值略大于1.535时，比如2.5350000000000000，第三位是5，这时候才会触发「五成双」规则，把第二位的3进成4，得到2.54。

至于为什么有的整数部分（比如101、102）加0.535后存成了略小的值，201、202却存成了略大的值？这是因为不同整数部分和小数部分组合后，对应的二进制浮点数近似值的方向会有差异，完全是浮点数存储机制的特性，没什么固定规律。

给你几个实用的解决办法 #

如果需要严格按照十进制的「四舍六入五成双」规则处理这类数值，可以避开原生浮点数的精度坑：

1. 用十进制精度的数值类型：
   可以用Rmpfr包或者decimal包来精确存储十进制小数，这些包会用字符串或专门的十进制格式保存数值，避免二进制转换的误差。比如用Rmpfr的示例：

   library(Rmpfr)
   x <- mpfr("1.535", 50) # 用50位精度存储精确的1.535
   round(x, 2)
   # 输出会是1.54，完全符合预期
   

2. 手动缩放为整数处理：
   先把数值乘以100转成整数（如果是保留两位小数的话），避开小数的精度问题，处理完再缩回去：

   round_exact <- function(x, digits) {
     scale <- 10^digits
     # 先缩放，用整数舍入逻辑，最后还原
     as.integer(x * scale + ifelse(x >= 0, 0.5, -0.5)) / scale
   }
   # 测试下
   round_exact(1.535, 2) # 得到1.54
   round_exact(101.535, 2) # 得到101.54
   

   不过这个方法在处理超大数值时可能会有整数溢出问题，所以如果是超大数场景，还是推荐用专门的十进制包。

总结下：你的猜测完全正确——不是round函数的舍入规则错了，而是我们输入的1.535在R里根本不是精确的0.535，只是个接近它的近似值，才导致最终舍入结果看起来不符合预期~