Ruby中attr_reader是否有弊端？getter返回冻结对象是坏实践吗？

你观察到的问题本质不是attr_reader的设计缺陷，而是Ruby「可变对象按引用传递」的默认特性。

完全应该正常使用，它只是一个帮你生成标准getter方法的语法糖，本身没有任何问题。
attr_reader :some_string生成的代码和你手写下面的内容逻辑完全一致：

def some_string
  @some_string
end

你遇到的外部篡改实例变量内部值的问题，就算不用attr_reader、手写上面的朴素getter也一样会出现，和这个语法糖没有关系。

日常开发里attr_reader是非常推荐的写法：

• 当你暴露的实例变量是不可变对象（Integer、Symbol、nil、布尔值、冻结的字符串等）时，不存在被外部修改的风险，用attr_reader最简洁高效
• 当你的类本身就设计为允许外部修改内部持有的可变对象状态时，attr_reader的默认行为完全符合设计预期
• 只有当你需要对返回值做额外处理（比如冻结、返回副本、计算派生值）的时候，才需要手写自定义getter，不需要因此完全弃用attr_reader

这不仅不是不良实践，反而是非常成熟的防御性编程手段，在Ruby生态的标准库、主流开源项目里非常常见，但是要注意匹配场景，不要无脑滥用：

• 如果你的类设计目标就是不允许外部修改内部持有的对象状态，返回冻结对象比返回对象副本（比如@str.dup）性能更好，不需要额外分配内存复制对象
• 更推荐的做法是在初始化实例变量的时候就直接把值冻结，而不是只在getter里冻结返回值：这种情况下不管是类内部的代码还是外部调用方，只要尝试修改这个值都会直接抛出错误，能从根源上避免状态被意外篡改，此时你依然可以正常用attr_reader，不需要手写getter，示例如下：

class X
  attr_reader :some_string
  def initialize
    # 初始化时就冻结内部值，内外都无法意外修改
    @some_string = "abc".freeze
  end
end

使用这种写法时，外部尝试执行tmp.some_string[0] = "a"会直接抛出你预期的冻结错误，代码比手写getter更简洁。

使用冻结返回值的注意点：

• 如果你后续需要在类内部修改这个实例变量的值，不要直接冻结原对象，这种场景下如果要阻止外部修改，应该在getter里返回对象的副本（比如@some_string.dup），否则类内部修改值时也会触发冻结错误
• Ruby的freeze是浅冻结：如果你持有的是嵌套结构的可变对象（比如存了字符串的数组、Hash），冻结外层对象不会让内部嵌套的对象也变成不可变，需要做深度保护的话要递归处理所有层级的对象。

最后总结：用不用attr_reader、要不要在getter里返回冻结对象，唯一的判断标准是你的类的状态设计意图——允许外部修改就返回原引用，不允许外部修改就用冻结/返回副本的方式做保护，二者没有冲突。

内容的提问来源于stack exchange，提问作者DimitrijeCiric