关注按钮需用data-following属性管理状态，点击后先禁用按钮并显示加载态，再用fetch发请求，成功后更新属性和文案，失败则还原；须用响应体字段同步状态，防重复点击并保障无障碍访问。
关注按钮的 DOM 结构和基础状态管理
关注按钮本质是一个可切换状态的交互控件，不是单纯靠 <button> 标签就能完成的——它必须承载「已关注」和「未关注」两种视觉与语义状态。直接写死文字或 class 容易导致状态不一致，比如点击后 UI 变了但后端没响应，或者用户刷新页面后按钮又回到初始态。
推荐用一个带状态标记的容器包裹按钮，例如：
<div class="follow-wrapper" data-following="false"> <button class="follow-btn">关注</button> </div>
这样后续 JS 可以统一读取 data-following 属性做判断，也方便服务端渲染时注入真实状态。
-
data-following值为"true"或"false"字符串（注意是字符串，不是布尔值），避免 JS 中误判为 truthy/falsy - 不要依赖纯 CSS 类名（如
.is-following）来判断状态，类名可能被其他逻辑干扰或未及时更新 - 如果按钮需要支持无障碍访问，记得在状态切换时同步更新
aria-pressed属性
用 fetch 实现关注/取消关注请求并更新 UI
点击按钮后必须发请求、等响应、再改 UI，不能先改 UI 再发请求（否则失败时 UI 就错乱了）。常见错误是忽略网络异常或 HTTP 错误状态，导致按钮卡在“正在关注”或直接静默失败。
立即学习“前端免费学习笔记（深入）”；
关键点在于：请求成功才更新状态，失败则还原或提示；整个过程要防重复点击。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 点击后立即将按钮设为
disabled并临时显示加载文字（如正在处理...），防止连点 - 用
fetch()发 POST 请求，URL 通常类似/api/user/123/follow（关注）或/api/user/123/unfollow（取消） - 检查
response.ok和response.status，401/403 要跳登录，404 要提示用户不存在，500 需降级处理 - 成功后更新
data-following属性，并切换按钮文字：关注 → 已关注或已关注 → 关注
示例片段（不带错误兜底的最小可行版）：
const btn = document.querySelector('.follow-btn');
const wrapper = btn.closest('.follow-wrapper');
btn.addEventListener('click', async () => {
const isFollowing = wrapper.dataset.following === 'true';
const url = isFollowing
? '/api/user/123/unfollow'
: '/api/user/123/follow';
btn.disabled = true;
btn.textContent = isFollowing ? '取消中...' : '关注中...';
try {
const res = await fetch(url, { method: 'POST' });
if (res.ok) {
wrapper.dataset.following = isFollowing ? 'false' : 'true';
btn.textContent = isFollowing ? '关注' : '已关注';
}
} finally {
btn.disabled = false;
}
});
服务端返回状态不一致怎么办
前端靠 data-following 判断状态，但如果服务端返回的响应体里也带了新状态（比如 {"following": true}），而你没用它去覆盖本地属性，就可能出现「点完显示已关注，但刷新后又变回关注」——说明前后端状态没对齐。
这不是前端能单方面解决的问题，但你可以主动对齐：
- 每次请求成功后，优先用响应体里的
following字段更新data-following，而不是靠 JS 本地取反 - 如果响应体没返回状态字段，要求后端补上；如果后端坚持不返，至少保证接口幂等且状态变更可查（比如 GET /api/user/123/following 返回当前状态）
- 不要假设「关注成功 = 状态取反」，用户可能在别处（App、其他浏览器）已操作过
样式和交互细节容易被忽略的地方
按钮看起来小，但细节一多就容易出问题：比如悬停态没区分状态、键盘焦点丢失、移动端点击反馈弱、取消关注没二次确认……这些不是“锦上添花”，而是影响真实转化的关键。
- 用
:hover和:focus-visible分别定义鼠标和键盘用户的反馈，别只写:focus - 「已关注」状态下，建议加个微弱的视觉差异（比如文字颜色变灰、加个勾图标），但不要禁用按钮——用户得能点进去取消
- 取消关注操作建议加轻量确认（如 tooltip 提示“再次点击取消关注”），而不是弹窗；弹窗在移动端体验差，且容易被拦截
- 如果按钮在列表里批量出现，确保每个
data-following和对应 API 的 ID 是一一绑定的，别用全局变量或闭包搞混了上下文
最麻烦的往往不是怎么实现，而是状态同步时机——比如用户快速连点两次，或网络慢到请求发出前就点了第二次。这时候光靠前端防抖不够，得和服务端约定幂等 key 或乐观锁机制。
