\_data前缀不能真正实现私有数据，因其仅为命名约定，无语言级访问控制；javascript（es2022前）无真正私有属性，typescript的private仅编译期检查，运行时仍可访问。
为什么用 _DATA 前缀不能真正实现私有数据
直接说结论：_DATA 前缀只是命名约定，不是语言级的访问控制机制。JavaScript 中没有真正的“私有属性”（ES2022 之前），_DATA 这类下划线前缀仅表示“请勿直接访问”，但任何代码都能读写 obj._DATA。TypeScript 的 private 也只在编译期检查，运行时照样可访问。
_DATA 前缀在 class 中的实际用法和风险
常见写法是把内部状态挂到实例上，比如：
class Cache {
constructor() {
this._DATA = new Map();
}
set(key, value) {
this._DATA.set(key, value);
}
get(key) {
return this._DATA.get(key);
}
}
这种模式的问题在于：
-
_DATA可被外部任意修改：cache._DATA.clear()直接破坏封装 - 多个类共用同名前缀时容易冲突（比如两个库都用
_DATA存 Map） - 调试时在 console 里一眼看到一堆
_属性，反而干扰判断真实公共接口 - 不支持私有字段的旧环境（如 IE、Node.js #data 替代，只能妥协用下划线
比 _DATA 更可靠的替代方案
如果目标是“运行时不可篡改+逻辑隔离”，优先考虑以下方式：
- 用
#data私有字段（ES2022+）：class X { #data = {}; get() { return this.#data.x; } }—— 外部完全无法访问，语法强制 - 闭包封装（兼容性最好）：
function createCache() { const data = new Map(); return { set() { data.set(...) } }; } - WeakMap 模拟私有存储：
const _DATA = new WeakMap(); class X { constructor() { _DATA.set(this, {}) } }—— 无命名污染，且垃圾回收友好 - Symbol 作键名：
const DATA = Symbol('DATA'); this[DATA] = {}—— 不会被for...in遍历到，但Object.getOwnPropertySymbols()仍能拿到
如果必须用 _DATA，至少做到这三点
当项目受限于老旧环境或团队规范强制要求时，可降低风险：
- 统一声明位置：所有
_DATA必须在 constructor 里初始化，避免后期动态添加导致类型推断失效 - 配合 TypeScript 接口隔离：
interface PrivateFields { _DATA: Map<string unknown> }</string>，并在函数参数中显式标注(this: PrivateFields & PublicAPI) - 加 ESLint 规则禁止外部访问：
no-restricted-properties配置项拦截obj._DATA这类直接读写
真正难的不是加下划线，而是让协作的人相信“别碰它”——而信任需要机制兜底，不是靠命名自觉。
