前端必须在数据进入组件前显式过滤敏感字段，如用Object.keys+reduce剔除id_card等键生成新对象，而非依赖UI隐藏或字段混淆；后端应负责裁剪，前端仅接收最小必要字段集。
敏感字段名在前端被直接暴露的典型场景
只要后端返回的 json 数据里带着 user_password、id_card 这类字段，哪怕页面没渲染，开发者工具 network 面板里一眼就能看到——这不是“藏得不够好”，是根本没做剥离。
常见错误现象：fetch('/api/user').then(res => res.json()).then(data => console.log(data)) 之后，控制台明文打印出完整对象；或者用 v-model 或 {...data} 直接解构赋值，导致敏感字段意外进入响应式状态。
- 别依赖「前端不展示就安全」——UI 层混淆 ≠ 数据隔离
- 后端应负责字段裁剪，前端只接收最小必要字段集
- 若必须由前端处理（如 legacy 接口无法改），需在数据进入组件前做显式过滤，而非靠 CSS
display: none或v-if="false"
用 Object.keys + delete 或 reduce 清洗响应数据
拿到 API 响应后立刻剔除敏感键，是最轻量、兼容性最好的做法。比用 Proxy 拦截或重写 getter 更可控，也避免 Vue/React 的响应式系统意外追踪到不该存在的字段。
示例：假设后端返回 {id: 1, name: "张三", id_card: "110...", phone: "138..."}，而 UI 只需 name 和 id：
const safeData = Object.keys(rawData)
.filter(key => !['id_card', 'phone'].includes(key))
.reduce((acc, key) => {
acc[key] = rawData[key];
return acc;
}, {});
-
delete也可用，但会修改原对象；reduce生成新对象更安全，尤其配合 React 的不可变更新习惯 - 敏感字段列表建议抽成常量，比如
const SENSITIVE_FIELDS = ['id_card', 'bank_account', 'user_password'] - 注意：字段名大小写敏感，
ID_CARD和id_card要分别处理
Vue / React 中防止敏感字段意外进入响应式或 state
框架的响应式机制会让任何被赋值的属性自动可追踪，一旦敏感字段混入 data 或 useState 初始值，就可能被序列化、打印、甚至透传到子组件。
- Vue 2：不要用
this.$data = {...rawData}，改用Object.assign(this.$data, safeData)或单独赋值this.name = rawData.name - Vue 3：
ref或reactive初始化时，传入的必须是清洗后的对象，不能先reactive(rawData)再删字段 - React：
useState(rawData)是高危操作；应写成useState(() => pick(rawData, ['id', 'name']))，或用useMemo做惰性清洗 - 特别注意 computed / derived state：如果
computed依赖了含敏感字段的对象，其 getter 内部仍可能访问到原始字段
混淆字段名 ≠ 隐藏数据，别用 base64 或简单替换骗自己
把 id_card 改成 a2VkX2NhcmQ= 或 userInfo_001，只是让人工阅读变慢，对脚本无任何防护力——JSON.parse 后照样能遍历所有 key，正则也能匹配模式。
- 混淆字段名唯一合理用途：规避某些老旧 SDK 或埋点工具的硬编码字段名检测（如它只认
uid不认user_id） - 若真需要字段映射，应在后端统一做 alias，前端只按约定字段消费；前端自行映射容易漏、难维护
- 真正要防的是「数据存在」，不是「名字难猜」。混淆 + 不传输，才是组合技；只混淆，等于锁了门却把钥匙塞在门垫下
最易被忽略的一点：接口文档、mock 数据、TypeScript 类型定义里如果还留着敏感字段名，开发时就会下意识当成可用字段——清理必须贯穿整个链路，从 OpenAPI spec 到 .d.ts 文件。
