简介：一款面向微博用户的隐藏辅助工具，主打“自己可见”式批量处理，解决逐条手动隐藏微博的麻烦。主文件为weibo-hide-all.js，通过Chrome控制台执行fetch调用脚本后即可自动遍历并隐藏微博；整套资源仅6KB，共3个文件，包含核心js脚本、README说明文档和开源许可证，结构精简，方便快速查看源码逻辑与使用方式。目前已有760人学习下载，适合具备基础浏览器调试能力、想掌握自动化脚本写法的前端学习者。借助这份小体积工具，可以直观了解fetch拉取远程脚本、eval执行、类封装以及页面元素批量隐藏的完整思路；同时干净的文件划分也为二次开发或迁移至其他社交平台提供了清晰参照。 去年有一阵子我突然想收拾一下自己的微博主页，翻着翻着就尴尬了：七八年前转发的中二内容、随手发的牢骚、早就忘了来龙去脉的日程碎碎念……全都在主页上摊着。手动一条条改成"仅自己可见"，点了十几条就烦了，太慢了。于是干脆写了个小工具，起名叫weibo-hide-all，作用就是把当前账号的全部微博一键批量设置成"自己可见"。
这个项目本身不复杂，是个纯前端自动化的小脚本，你登录微博网页版，在个人主页打开浏览器控制台跑一下就行，不需要装额外软件，也不用求人开接口权限。整个过程顺便把滚动加载、DOM解析、批量操作这些前端基本功都过了一遍，我做完之后顺手整理了一下，这篇就当作完整复盘，把思路、实现细节、踩过的坑都摊开来讲清楚。适合在网上冲浪时想快速清理主页、又不想一条条手动操作的朋友，也适合刚上手油猴脚本或控制台脚本的开发者拿来做练习。
1. 为什么要做的"全部微博自己可见"：需求场景拆解
1.1 手动操作的痛点在哪里
微博早期的内容策略是"公开是默认态"，发出去的东西默认所有人都能看见。平时大家发动态也就是随手一发，没想那么多，但等时间久了回头看，主页上什么内容都有：跟朋友repo的日常、吐槽老板的碎碎念、转发的抽奖、带定位的打卡……有些内容被无关的人看到就会觉得不舒服。
要把这些内容隐藏起来，微博网页版提供的方式是逐条操作：鼠标移到某条微博上，点右下角的小箭头，在弹出来的菜单里选择"仅自己可见"。听起来不复杂，但真正操作起来就痛苦了：
- 每条微博都要单独点击两次，一次展开菜单，一次选择权限，两条微博之间还得等页面反应过来；
- 微博主页是无限滚动的，今天看了一部分，明天再点开，又得重新往下拉；
- 几年攒下来的几百上千条微博，手动操作意味着重复几百上千次点击，而且中途手滑点错还可能把不该公开的公开了。
实测手动处理 100 条大概要 10 到 15 分钟，如果微博有一千条，就得一两个小时。这完全是有规律、可重复、能自动化的操作，没必要浪费生命。
1.2 可能的实现思路与场景延伸
所以当时我的判断很简单：找到批量处理的方法，让它自己跑。可行的路线有三条：
- 浏览器控制台脚本：利用网页端的 DOM 结构，遍历当前页面上已加载的微博，逐条模拟点击设置权限。优点是简单直接、不需要额外工具，缺点是受微博前端结构变化影响大；
- 浏览器油猴脚本（Tampermonkey）：本质还是浏览器端脚本，但可以把代码挂载到指定页面自动运行，方便重复使用、分享给别人；
- 接口请求方式：分析微博网页端发送的修改权限的请求，拿到登录态后，直接请求接口批量更改权限。速度最快，但需要处理加密参数、Cookie 有效期等问题，维护成本也高。
对比下来，前两种方案的门槛和风险都小很多，实际执行效果也完全够用。我最终选择了控制台脚本为主、附带简单版本的油猴封装，这也是 weibo-hide-all 项目的核心实现逻辑。
2. 工具的核心原理与机制
2.1 weibo-hide-all 的底层工作逻辑
不管脚本怎么封装，做的事情无非是三步：加载全部微博 → 定位可见的微博条目 → 模拟点击设置"仅自己可见"。
第一步是滚动加载。微博个人主页默认只会加载最近几十条，想处理全部内容，必须先让页面把历史微博都加载出来。实现方式是在控制台跑一个循环滚动的函数，不断把页面滚动到底部，页面会自动发起 AJAX 请求加载接下来的内容，滚动一次、等待内容渲染、再滚动，直到页面高度不再变化。
第二步是定位微博条目。微博网页版经过多次改版，DOM 结构经常调整，但总有一条可循的规律：每条微博最外层有一个独立的容器节点，容器的右下角有一个触发下拉菜单的控件。脚本要做的就是用 DOM 选择器把当前页面上所有这样的容器节点找出来。
第三步是模拟操作。对每个容器节点，通过 JavaScript 触发对应控件的 click 事件，让权限菜单弹出，再从菜单里选中"仅自己可见"这个选项。这个操作本质上是替你完成了手动点击做的事情，所以不会绕过任何平台规则，和你自己一个个点完全等效。
2.2 为什么选择"视觉化模拟点击"方案
写脚本的时候，最容易想到的是直接调用微博的接口，把某条微博的可见范围从"公开"改成"仅自己可见"。这个路子确实快，一次请求就能搞定一条，几百条微博理论上几秒钟就能完成。
但我实测后放弃了这个方案，原因有三个：
- 门槛高：需要从浏览器开发者工具里找到修改权限的接口地址，还要带上完整的 Cookie、Referer、以及微博自己生成的请求签名参数，任何一个字段不对就会被拒绝；
- 稳定性差：微博服务端的参数校验策略经常变，今天能用的请求格式，明天可能就返回错误码，脚本需要长期维护；
- 风险大：直接在接口层批量操作，行为特征和正常用户差别很大，容易触发风控策略，轻则验证码，重则临时限制操作。
模拟点击方案看起来"笨"，但胜在每次点击都是真实浏览器环境中的一次真实操作，和用户手动设置几乎没有行为差异，触发风控的概率要小得多。性能上虽然比接口慢，但一次批量操作也就是几分钟的事，完全能接受。
提示：不管用哪种方案，操作自己的账号是合规的。但如果你掌握了某个自动化方法，不要拿去处理别人账号的内容，也不要批量操作来绕过平台管控，这是底线问题。
3. 安装与使用：一步步操作全流程
3.1 准备工作
weibo-hide-all 是纯前端的脚本，依赖的东西很少。你需要准备的只有：
- 最新版的 Chrome、Edge 或 Firefox 浏览器；
- 一个正常登录状态的微博网页版账号；
- 打开浏览器开发者工具的快捷键记一下（Chrome/Edge 是 F12，Mac 上是 Cmd+Option+I）。
准备工作只需要确认你的浏览器控制台能够正常执行 JavaScript，并且你有权限操作微博网页版页面。不需要安装 Python、Node.js 等任何运行环境。
3.2 详细操作步骤
我以最常用的控制台运行方式为例，按步骤走完全程。
第一步，进入微博个人主页。
登录微博网页端（weibo.com），点击页面右上角个人头像，进入自己的个人主页。此时地址栏里的 URL 类似https://weibo.com/u/你的UID，也可能带一些额外参数，不管它，这里是脚本运行的起点。
注意：脚本只对当前打开的页面生效。如果你有多份账号，记得只保留当前登录的这个，以免误操作到其他账号。
第二步，打开开发者工具。
按 F12 打开开发者工具面板，切到 Console（控制台）标签页。如果你之前没怎么用过控制台，这里看到的是一个有点像命令行的地方，可以直接输入代码回车运行，这就是我们要用的环境。
第三步，执行滚动加载函数，让全部微博显示出来。
微博是分页加载的，不滚动就不会加载历史内容。直接在控制台粘贴以下代码，回车运行：
async function autoScroll() { let totalHeight = 0; let scrollAttempts = 0; const maxAttempts = 200; // 上限保护，防止异常死循环 while (scrollAttempts < maxAttempts) { const before = document.body.scrollHeight; window.scrollTo(0, before); // 等待页面加载新内容 await new Promise(r => setTimeout(r, 300)); const after = document.body.scrollHeight; // 如果滚动后高度没变，说明到底了 if (after === before) { scrollAttempts++; // 连续 5 次高度没变化，判定加载完成 if (scrollAttempts >= 5) break; } else { scrollAttempts = 0; } } console.log('滚动加载完成，已到达底部或不再有新内容'); } autoScroll();注意脚本设置了maxAttempts = 200，这是为了防止万一页面本身有问题时脚本无限滚下去。微博内容少的话，大部分情况十几秒就到底了；内容很多的话，这个函数会持续滚动直到全部加载完，过程中控制台会不断输出提示，等它安静下来就说明加载完了。
第四步，运行批量设置脚本。
滚动完成后，粘贴下面的代码到控制台运行：
(function hideAllVisiblePosts() { // 每一轮最多处理 50 条，处理完一轮休息一下，避免把页面卡死 const BATCH_SIZE = 50; const DELAY_MS = 500; // 每一个需要处理的微博节点 function isPostCard(el) { return el && el.getAttribute('mid') !== null; } function findController(postNode) { // 优先在卡片右下角范围内找按钮 const actionList = postNode.querySelector('[class*="action"]'); if (actionList) return actionList; return null; } function clickHideOption(container) { // 展开下拉菜单后，找到文字为“仅自己可见”或包含相关图标的选项 const items = document.querySelectorAll('[class*="dropdown"] li, [class*="menu"] li, [class*="popover"] li'); for (let item of items) { const text = (item.innerText || '').trim(); if (text.includes('仅自己可见')) { item.click(); return true; } } return false; } async function run() { const cards = Array.from(document.querySelectorAll('[class*="Card"]')).filter(isPostCard); let processed = 0; for (let i = 0; i < cards.length; i++) { const card = cards[i]; const ctrl = findController(card); if (!ctrl) continue; ctrl.click(); await new Promise(r => setTimeout(r, 300)); const ok = clickHideOption(card); processed++; if (ok) { console.log('已设置隐藏', i + 1 + '/' + cards.length); } else { console.warn('未找到“仅自己可见”选项', i + 1); } // 每处理一批停下来，给页面喘息时间 if (processed % BATCH_SIZE === 0) { console.log('已完成 ' + processed + ' 条，休息一下'); await new Promise(r => setTimeout(r, DELAY_MS)); } } console.log('本次处理完成，共处理 ' + processed + ' 条'); } run(); })();脚本会遍历当前页面的所有微博卡片，在每个卡片上找到操作按钮，点开下拉菜单后，按文本匹配方式找到"仅自己可见"并点击。
这里有个细节：代码里用了[class*="Card"]这个模糊选择器来匹配微博的卡片容器。不同时期微博卡片类名都不一样，我写这个版本是基于 2023 年底到 2024 年常见的类名结构。如果微博改了前端结构，你看到的效果可能不同，后面我会专门讲怎么排查和修复。
第五步，检查结果。
运行完脚本后，回到微博主页，刷新页面，确认所有历史微博是否都已经显示为"仅自己可见"。如果滚动加载那一步中途断了，刷新后重新走一遍流程即可。脚本本身是幂等的，即使某条微博已经被设置成"仅自己可见"了，再运行一次也不会出问题。
3.3 油猴脚本封装：重命名与便利性
控制台脚本的缺点是每次都要把代码复制粘贴进去。如果你需要经常使用这个功能，建议把它封装成一个油猴脚本，这样每次进入个人主页就自动运行，连控制台都不需要打开。
油猴脚本的本质是在页面加载时自动注入 JS。你只需要装好 Tampermonkey 扩展，在扩展面板里新建一个脚本，把上面的 JS 代码包在一个(function(){ ... })();的结构里，再配上@match规则，匹配https://weibo.com/u/*这个地址，保存后刷新微博主页，脚本就会自动执行。
油猴封装的价值不只在于省去复制代码。你还可以把需要确认的逻辑抽出来，比如首次运行时弹一个确认框，防止不小心进入页面就直接执行批量操作。我觉得这个功能很重要，因为微博个人主页是高频访问页面，如果脚本无脑自动运行，很容易在生产环境里误伤还没准备好的内容。后来我加了一个confirm('是否执行批量隐藏？')的前置确认，体验瞬间安全很多。
4. 常见问题与故障排查
4.1 微博改版了，按钮找不到了怎么办
这是所有前端自动化脚本都逃不掉的坑。微博的 DOM 结构和类名经常调整，哪怕是同一年内的版本，不同机型、不同账号状态下看到的页面也可能不一样。
排查思路不是去改脚本里每一个类名，而是先搞清楚当前页面长什么样。在微博主页按 F12，用开发者工具的"选择元素"功能，鼠标移到你想要点击的那个按钮上，看它有什么特征。然后调整脚本里的 CSS 选择器和关键词匹配规则。
具体来说，如果点了操作按钮但菜单没弹出来，先在控制台执行一句：
document.querySelectorAll('[class*="action"]').length看返回的数字是不是 0。如果是 0，说明类名已经完全变了，需要重新找按钮的定位方式。如果数字正常，再看菜单选项的文本："仅自己可见"这个文字的措辞有没有变（比如改成"设为仅自己可见"），如果变了，把includes('仅自己可见')改成对应的新文本即可。
4.2 脚本卡在滚动加载阶段，一直不结束
微博的滚动加载并不总是那么顺畅。可能的原因有三类：
- 网络慢：页面还在等待接口返回，但你的脚本已经等不及了。解决方法是把每次滚动的等待时间从 300 毫秒加到 800 到 1000 毫秒，并把连续无变化的次数阈值从 5 次提高到 10 次；
- 页面懒加载策略变了：微博可能把滚动加载从"滚动到底就加载"改成"滚动到底还要再等几秒"，甚至要求用户点击"查看更多"。这种情况下，脚本就不能只靠滚动，需要额外判断页面上是否出现了"查看更多"之类的按钮，如果有就点掉；
- 到了真实底部但检测逻辑有误：连续 5 次高度不变就判定到底，这是经验值，如果网络抖动导致页面高度短暂不变化，可能误判。我把阈值提高之后，这个问题基本消失了。
4.3 批量操作时提示"操作频繁"或触发了验证码
这属于最让人糟心的情况，但其实是减速没做好。
微博对操作频率有隐形限制，短时间内在大量微博上执行点击操作，很容易触发异常检测。解决办法是在脚本里加入随机延时。每次操作之间不要用固定的 300 毫秒，而是改为随机生成 400 到 900 毫秒的间隔，让行为更像真人操作。
实测下来，随机延时脚本跑一整天都没问题，固定延时的版本在操作几百条之后就会遇到验证码弹窗。等脚本跑完之后，再手动输入一次验证码就能恢复正常，不会对账号产生持久影响。
提示：操作频率是一个经验值，没有绝对标准。如果微博加强对异常操作的检测，可能需要把延时拉得更长。好好保护自己的账号比一次跑完更重要，哪怕多花几分钟也值。
4.4 脚本运行完了，但微博数量比较多，只处理了部分
这种情况几乎百分百是滚动加载没有把全部微博都加载出来。很多人在执行批量脚本前，没有先跑滚动加载，或者滚动加载中途被中断了。
微博的滚动加载有一个上限保护机制，默认最多加载 1000 条左右。如果你的微博超过这个数量，滚动到底之后还有更多内容，但页面不会自动加载。这时你需要刷新页面，然后多滚动几次，或者手动点击页面上的"加载更多"按钮把剩余内容刷出来。不过说实话，真有一千条以上微博的话，我建议你换个思路：按月份分批处理，比如只处理某年某月的内容，比一次性处理全部历史内容更可靠。
5. 项目总结与扩展建议
5.1 做个项目复盘
weibo-hide-all 这个项目给我最大的感受是，很多看似繁琐的重复操作，拆解下来都有自动化的可能性。它需要的技术知识并不高深，核心是三条：理解页面的 DOM 结构、理解什么时候可以安全地模拟操作、理解怎么让脚本运行得足够温柔。
写这个脚本的经历也让我养成了几个习惯：不管多简单的脚本，都加上超时保护和随机延时；跑批量操作前，先在小范围试跑一遍确认选择器无误；操作前认真看页面结构而不是凭记忆写类名。
5.2 可以怎么继续扩展
如果想让 weibo-hide-all 做得更完善，有几个方向值得尝试：
- 增加内容预览功能：运行脚本前，先把即将设置的微博标题或前 50 字列出来，让你确认哪些可以隐藏、哪些需要额外处理；
- 精确筛选：支持只隐藏某段时间内的微博、只隐藏带图片的微博、只隐藏转发内容等，让它从"全部隐藏"变成"按条件隐藏"；
- 反向操作：如果你某天想重新公开某条微博，脚本逻辑可以倒过来用，只要把"仅自己可见"换成对应选项即可；
- 做成独立工具页：可以把控制台逻辑包装成一个简单的 Web 页面，输入 UID 后自动在后台执行，体验会更好。
这次项目做到最后，我反而建议大家动手前想清楚自己的目标是什么。是清理我个人主页上的黑历史？是减少公共可见的信息暴露？还是单纯想学自动化脚本？目标不同，方案选择会很不一样。对我来说，做这个工具最有意义的不是脚本本身，而是让我真正搞懂了微博前端页面的运行逻辑，以后再遇到类似的网页自动化需求，都能快速上手了。
本文还有配套的精品资源，点击获取
