HTML 无“仅自己可见”原生属性，该功能必须由后端控制数据输出与接口鉴权，前端仅能依据服务端状态做条件渲染或UI显隐，hidden和display:none均不具安全意义。
HTML 里没有“仅自己可见”或“成就隐藏”的原生属性
HTML 是纯展示层标记语言，不处理权限、用户身份或可见性逻辑。所谓“仅自己可见”，本质是服务端根据登录态动态渲染 DOM，或前端 JS 根据当前用户角色做条件渲染——HTML 本身不存这类语义。
常见错误现象：display: none 硬写在 HTML 里、用 hidden 属性但没配合后端校验、把敏感内容直接塞进 HTML 注释里，这些都毫无安全可言。
- 所有 HTML 内容对客户端完全透明，
hidden属性和display: none都能被开发者工具轻易取消 - 搜索引擎、爬虫、辅助技术仍可能读取
hidden元素（取决于具体实现） - 真正需要“仅自己可见”的内容（如未公开成就），必须由后端决定是否输出该 HTML 片段
如何让“成就隐藏开关”在前端表现合理
前端能做的，只是响应后端传来的状态，控制 UI 的显隐与交互。关键不是“怎么藏”，而是“藏得有没有误导用户”。
使用场景：用户进入个人主页，看到「我的成就」区域有个「设为仅自己可见」按钮；点击后，UI 变化，同时向后端提交更新请求。
立即学习“前端免费学习笔记（深入）”；
- 按钮本身应有明确状态反馈，比如用
data-visibility="private"或aria-pressed="true"标记当前设置 - 不要仅靠 CSS 隐藏整个成就区块，而应在 DOM 中保留占位或提示文案（例如
<div class="achievement-private">该成就已设为仅自己可见</div>） - 若需本地缓存开关状态（避免频繁请求），用
localStorage.setItem('achievement_privacy', 'private')，但每次页面加载仍须以服务端返回值为准
后端必须参与的两个硬性环节
前端任何开关、切换、显示/隐藏，都只是表象。真正起作用的只有两处：数据输出前的过滤，和 API 接口的权限校验。
常见错误现象：前端 JS 把成就列表全拉下来，再用 if (user.id === myId) 过滤显示——此时所有成就数据已暴露在 Network 面板中。
- 成就列表接口（如
/api/v1/users/{id}/achievements）必须校验调用者身份，非本人请求时直接返回空数组或 403 - 渲染 HTML 模板时（如 SSR 或模板引擎），必须用服务端变量判断：
{% if current_user.id == target_user.id %}...{% endif %} - 如果用 JSON + 前端渲染，API 返回字段应包含
"visibility": "private"，前端据此决定渲染逻辑，而非自行推断
别踩这个坑：用 hidden 属性假装实现了隐私控制
hidden 是 HTML5 提供的布尔属性，语义上表示“暂不相关”，但不等于“不可见”或“不可访问”。它和 display: none 效果类似，但更轻量、可被 JS 动态切换，也支持 CSS 选择器 [hidden]。
性能影响极小，兼容性也好（IE10+），但它解决不了任何权限问题。
-
<div hidden>LV.99 神级成就</div>—— 用户打开 DevTools，删掉hidden就立刻看见 - 屏幕阅读器默认跳过
hidden元素，但某些模式下仍会读出（尤其配合aria-hidden="false"时） - 如果你真要用它，只适合临时 UI 状态（比如加载中占位、表单步骤切换），绝不能用于敏感信息掩藏
复杂点在于：用户心理预期和系统实际能力之间存在落差。“设为仅自己可见”听起来像一个开关，但背后涉及鉴权、缓存、同步、竞态等多个环节。最容易被忽略的是——前端切换了开关状态，却没等后端确认就更新 UI，结果刷新页面发现又变回公开了。
