封装的本质是控制访问路径而非仅隐藏属性，需在setter中嵌入校验、getter返回防御性副本、构造函数拒绝非法状态，并依据协作场景合理暴露接口，区分封装与加密。
封装不是加个 private 就完事了
封装的本质是“控制访问路径”，而不是单纯把属性藏起来。很多人写 private 字段 + public getter/setter，就以为完成了封装，结果发现 age 还是能被设成 -5、name 被赋值为 null 或空格串，业务逻辑照样崩——这说明只做了形式封装，没做语义约束。
- 真正有效的封装，必须在 setter 里嵌入校验逻辑，比如
setAge(int age)中检查age >= 0 && age - getter 也不只是返回值，有时要返回防御性副本（如
return new ArrayList(this.items)），避免外部直接修改内部集合 - 构造函数也要承担封装责任：不允许创建半初始化对象，比如
new Person(null, -1)应该抛IllegalArgumentException
JavaScript 里怎么模拟私有？别只靠下划线
JS 没有原生 private（ES2022 才有 # 私有字段），但开发者常误用 _name 这种命名约定当“私有”，结果别人照样能读写，根本起不到保护作用。
- 真要隔离，优先用
#语法：#age = 0;+getAge() { return this.#age; }，这是目前唯一运行时强制私有的方式 - 模块顶层的闭包变量也有效：
const _balance = new WeakMap();存实例私有状态，外部无法枚举或访问 - 千万别用
Symbol模拟私有——它可被Object.getOwnPropertySymbols()拿到，只是“难找”，不是“不能碰”
封装过度反而破坏协作：什么时候该暴露？
封装不是越严越好。强行隐藏所有细节，会导致测试写不了、调试抓瞎、下游被迫反射或 monkey patch，最后演变成更脆弱的耦合。
- 工具类方法（如
formatDate()、deepClone()）本就不该封装成实例方法，放静态工具模块更合理 - DTO 或配置对象（如
ApiConfig）通常需要全开放属性，加一堆 getter/setter 只是增加噪音 - 日志、监控、序列化等场景需要读取内部状态时，可以提供
toDebugString()或inspect()这类明确标注“仅用于调试”的公开方法
封装和加密不是一回事，别混用术语
有人看到“封装保护数据”，立刻联想到 AES 加密、EFS 磁盘加密——这是概念错位。封装解决的是代码层面的访问控制与契约边界；加密解决的是存储/传输过程中的机密性问题。
- 一个
Account类把#passwordHash设为私有，是封装；把它用AES-256加密存进数据库，是加密——两者目标不同、手段不同、失效场景也不同 - 封装失效，顶多是业务逻辑被乱调用；加密失效，可能直接导致用户密码明文泄露
- 实际项目中，这两层都得有：封装管“谁能在代码里怎么用”，加密管“数据落在哪、被谁看到”
最常被忽略的一点：封装的边界必须和团队协作节奏对齐。接口暴露多少、校验多严、文档写到哪一级，取决于你是在写内部 SDK，还是交付给第三方集成的 API —— 同一套封装策略，在不同上下文里，可能一边是保护，一边是枷锁。
