2026-06-23 06:22:58
最近的独立博客圈可以说是热闹非凡，各路聚合平台的“大瓜”那是一个接着一个，直接把这个原本安静的小圈子炸成了火药味十足的江湖。
先是在 5 月底，主打生活类个人博客收录的“壹個博客（Oneblog）”被爆出在毫无预警、零告知、不留明确申诉通道的前提下，悄悄在后台对部分历史合规站点实行“静默封禁”。更有博主可能仅仅是因为注册邮箱同源，或者页面带有管理员认定的所谓“竞品链接”，就被不分青红皂白地进行了“株连式”的连带封禁。直到封禁事件闹大、舆论发酵之后，平台才赶紧修改收录和推送规则，打上了一个（并不算完善）的补丁：“（仅）收录兼具设计美感与日常生活长文的博客”。
而到了 6 月中旬，更大的瓜田来了，至今还陆续有新瓜爆出。“简笔记”系统被爆出评论区接口邮箱明文泄露 Bug，随后其开发者（同时也是“个站商店”的站长）在面对热心网友的 Bug 反馈时，不仅没有职业化地迅速复盘并修复问题，反而将群内“仅修复提及的文章还远远不够”的善意提醒，粗暴地回绝为“你这么关心这个干嘛？我比你知道”。后续，该站长又连续发表多篇文章，暗讽反馈者是“生活在底层、无所事事”的人。更有甚者，某个博主仅仅因为在 QQ 群里扮演和事佬“劝了几句”，其站点就在个站商店后台被悄悄静默删除。如果把视线再放宽到过去，诸如“积薪”、“川流”等聚合站点，也无一例外都在“三观不合”或“政治/观点交锋”后，在管理员与博主们的激烈争吵中走向了圈地自萌、淡出、停运的结局。
那，为什么这些独立的聚合站点，频频会在“审核标准”和“平台态度”这种最基本的运营层面上翻车呢？
很多人或许觉得，这些丑闻的爆出只是因为管理员的“素质问题”或者“技术硬伤”。但作为深度参与并管理过大大小小各类网络组织的人——从现实中母校历届的新生群/论坛/贴吧/频道管理，到母校公众号与迎新群的技术支持运营，再到百度贴吧、微博、知乎的审核志愿者，乃至 QQ 和 TG 上的万人社群管理——我感觉出现这种情况是个人主导的独立聚合站点在发展到一定阶段时，现实且必然的产物。
当一个社群还只是一套程序、一个域名的私人产物时，它只是一个“个人的自留地”。但当它戴上“平台”、“商店”、“聚合”、“社区”的帽子，吸引了大量独立博主主动入驻、提交 RSS 时，它在客观上就已经具备了公共属性。
那么，是不是只要摆脱了这种个人独裁的管理形式，改为多位成员共同维护的联合治理，或者开放式的公益组织，问题就能迎刃而解了？
答案是：不过是从“个人情绪的奴隶”这一大坑，跳进了新的“系统性结构缺陷”天坑里罢了。
随着团队的扩大，联合治理或开放式组织必然面临管理员素质水平鱼龙混杂的局面。这时候，组织者又不得不面对以下三个更为无解的现实困境：
这种松散的网络组织在建立初期之所以能高效运转，纯粹是靠初始成员间一种高度心照不宣的“气味相投”（隐性共识）。但这种单靠热情维持的共识是非常脆弱的。
营利性组织遇到内部观念冲突时，可以通过薪酬和组织架构强行消弭分歧——为了工资，大家可以“忍辱负重、求同存异”。
但一个松散的网络组织，既无薪酬利诱，又无强制权力。当组织规模扩大、各种带有不同价值观、不同利益诉求、不同立场的管理员涌入时，由于缺乏底层利益的捆绑，任何一次微小的技术切磋或观点交锋，都有可能会迅速上升为“路线之争”。
不管是否愿意承认，在一个没有经济收益的社群里，“话语权”和“认同感”就是衡量成功的唯一标准。正如公司以营业额和产值论成败，政府部门以组织规模和权力边界定高下。
当成员数量激增后，管理团队就不再是一个单纯的“热心网友集合体”，而是变成了一个微型的竞技擂台。由于网络社群的“退出壁垒”和“内耗成本”几乎为零（大不了退群、换个马甲、甚至直接拉走一拨人另立门户），这就导致了内部派系斗争的成本极低。
管理员们会本能地开始拉帮结派，代表各自背后的群体利益（例如技术激进派 VS 养老生活派）。此时，平台的管理权限（如封禁、置顶）不再是服务工具，而是变成了各派系在进行意识形态冲撞时、用来互相攻击和降维打击的资本。而很多时候，你作为最高管理者很难出面拍板，因为两边的选择可能都有其道理。你若和稀泥，搞不好两边都要得罪；你若选择站边，搞不好组织就面临分裂。
随着社群规模的扩大，日常维护的“脏活累活”（如处理垃圾评论、审核边缘违规、解决日常反馈、安抚巨婴用户）会呈指数级上升。
然而，志愿者从“用爱发电”中能获得的正向情绪反馈，却随着组织的臃肿在加速递减。这就导致核心干活的志愿者极易陷入严重的精神内耗与职业倦怠。在疲惫且没有任何物质补偿的情况下，有些管理者遇到其眼中的奇葩用户时，理智的弦就会崩断——“我凭什么在这里受你这个用户的气？”这种憋屈积累到顶峰，便会演变成一种“毁灭吧，赶紧的”的情绪暴政，随之而来的就是撕逼和开战。最糟糕的是，这位管理者的任性操作，往往最终并不会由其个人买单，而是需要整个组织为其背锅。
在管理了这么多年、这么多类型的社群组织后，我发现最幽默的情况莫过于：“组织者越是想要民主，反而越是容易遇到必须用不民主的方式去解决的事情。”
这倒不是说追求社群内民主是错误的，而是因为：作为一个一般水平的人类个体，想要把规则写到事无巨细、尽善尽美，是完全不可能的。
当组织还是小圈子、大家圈地自萌时，规则往往只是摆设，大家都乐呵呵的。但组织一旦做大破圈，林子大了什么鸟都有，你总会遇到你现有、不完美的规则里完全没有明确规定，但在现实中又不得不立刻做出处理的灰色案件或舆论危机。此时，微型社群根本不具备容纳复杂民主程序的成本空间。你既没有多余的精力去搞一场长达数天、数周乃至数月的大辩论，你为了体现民主风范也不会在争议刚露出苗头时就雷霆手段予以弹压。你等事情闹大了之后去搞民主意见收集，民主公投，结果往往不是看谁的说法更有理、更正确，而是变成看谁的粉丝多、谁更擅长拉帮结派带节奏。如果这个“节奏”恰好符合你内心的标准或者和多数人一致，那还能你好我好大家好，如果这个节奏恰好不符合你的内心标准呢？接受结果吧，你心里不舒服，不接受结果把，这时候再去搞弹压，那你的公信力可就彻底完蛋了。
更何况，我们聊的这种所谓社群民主，背后其实一直隐藏着一个所有人都在装傻的默认前提：“组织发起者的最高权威是神圣不可挑战的。”
大家可以扪心自问一个灵魂问题：如果你是一个聚合站点的发起者，你会在你设计的民主规则里，明确写上一条“成员有权通过公投罢免你”的机制吗？😂
你琢磨下，你有见过存在这种机制的聚合站吗？你肯定不会设置这种机制啊，因为随着你的聚合站点越做越大，你和外部的其他聚合组织、博主圈子之间，会不可避免地会产生摩擦、冲突和利益博弈（无论你在冲突中是对是错）。如果你的平台真有一套“可以罢免创始人”的民主机制，外部的敌对组织或看你不顺眼的群体，完全可以利用你的规则，通过恶意引流、拉帮结派、粉丝抱团渗透进你的管理层，然后堂而横之地“利用你的规则逼你下台”。
所以，这就把微型组织的民主逼入了一个死胡同：不给罢免最高领导人权力的民主，不过是一个披着民主外衣的“仁君独裁下的民主”，这层外衣什么时候被掀开，只需等到一个未来的必然；而给出了罢免权力的民主，在如今互联网上日益增长的派系斗争面前，对于体量如此小、颠覆成本如此低的组织而言，搞真民主就是纯粹的政治自杀。
如果把“独裁”或“民主”都否定掉，咱们选择走向彻底的“工具化”与“去中心化”——剥离一切人情和情感色彩，不设任何交流群，不搞精选推荐，只把平台当成一个“冷酷的、没有感情的 RSS 抓取脚本运行器”，是不是就能天下太平了？
听起来很美对吧？但这招看似美好，实则卵用都没。原因有二：
原本独立博客站长们就天然拥有极强的独立意识和表达欲（毕竟大家在众多可发言的平台中，选择了相对最独立的形式）,而你又不可能将规则写的完美无缺，就比如现在的壹個博客（Oneblog）虽然他已经修改完善了多次收录标准去阐述他不想收录非生活博客，并且 RSS 里过滤（IT）技术类文章是交给 AI ，排除了人的干扰，但还是有较真的博主在怼他。而且互联网上还永远不缺“巨婴”和“杠精”。哪怕你把自己的聚合站做成了一个纯技术、纯客观的自动化爬虫工具，只要有一天因为某个博主的服务器配置兼容问题、RSS 兼容问题、合规性问题，或者存储盘爆满导致 RSS 抓取异常断开了——在“归因偏差”的作用下，有些人也绝不会从自己身上找原因。他们会立刻在心里完成一套受害者叙事，跳出来指着你的鼻子破口大骂：“你为什么悄悄删除我？你为什么要针对我？你是不是在搞阵营？你这个站长怎么这么傲慢？”巨婴和杠精总会觉得是你在故意搞他，然后写文章挂你、骂你。你再有理，多来几次，对你精力的消耗也是实打实的。
我以前也曾动过心思，想要自己折腾一个博客聚合站。但最终，我打消了这个念头。
一方面是因为上述治理中无法回避的现实问题；另一方面是因为工作、家庭、现实社交等各种琐碎事务已经彻底占满了我的精力。曾经加入的组织，还存在的那就继续管着，组织哪天消失了就不再加入重建的了。把精力留给真实的生活。不过，虽然我个人选择了退场，但花开两枝，各表一枝：
在这个很容易吃力不讨好的泥潭里，依然有些组织和个人在认真办事。比如大家提过的“笔墨迹”与“BlogsClub”。没有什么高大上的口号，他们只是把平台当成一个真正的服务工具，给草根站长留了一份最基础的知情权和尊重。在大家都容易情绪上头的当下，这种克制和规范，真的挺难得的。
说实话，这些站长能把一个聚合站、一套系统无偿维护几年甚至十年，背后付出的精力和成本是实打实的，这点大家都心里有数。大家都是凡人，做了贡献，想在这个小圈子里图个好名声、要点正向反馈和认同感，这完全合情合理，一点毛病没有。之前我在《独立博客如何在“纯粹记录”与“理直气壮恰饭”间找到平衡》一文中就表达过我的观点：只要能达成一种对反馈的可持续的自洽就挺好的。
但让人觉得可惜的是，有些站长的心态在后期没摆正。大概是无偿付出了太久，心态失衡了，渐渐把公共平台当成了自己的私产。一旦遇到技术质疑或者意见不合，就觉得对方是来“砸场子”的，第一反应是嘴硬和拉黑。
他们一边割舍不下作为“圈内领袖”的那点精神回报，一边又在现实的纠纷里任由情绪失控，用拉黑、踢群、甚至人身攻击去解决问题。结果呢？自己辛辛苦苦熬了多少年才攒下来的那点贡献和路人缘，在几场闹剧里直接被自己给作没了。原本是一个奔着大团圆结局的美好剧本，最终却因情绪失控沦为晚节不保的反面教材，着实令人扼腕叹息。
互联网是有记忆的，你怎么对待用户，生态就会怎么评价你。
最后，向那些至今还在用良心维护圈子、默默干脏活累活的聚合站站长们致敬。至于我，还是安安心心当个读者，偶尔看看八卦、吃吃瓜就挺好。
排序不代表时间线
1. “简笔记”的作者，一位行为艺术家
2. 博客 RSS 遭一个博客聚合平台连带封禁
3. “>个站商店悄悄的删除我的博客>
4. 简笔记这套付费系统，十年了老bug还在反复发作
5. 聚合博客与独立博主的自主选择
6. 深扒博客聚合与博主们的江湖恩怨
7. 壹個博客聚合平台无通知封禁我的博客RSS
8. 邮箱泄露只是开始，简笔记的问题不止这些
9. 个站商店、简笔记泄邮箱后，阶级哥在群里破防了
本文 乾纲独断还是民主治理？聊聊博客聚合平台的治理悖论与无解之痛 最初发表于 秋风于渭水。
2026-06-17 10:18:35
根据目前披露的安全公告，这个漏洞（CVE-2026-53519 路径穿越）的严重程度高达 9.1 分，属于致命级。
这个漏洞简单来说，攻击者只需要利用哪吒探针的“前缀混淆”逻辑 BUG，构造含有特殊字符的 URL（比如包含 /dashboard..），就能直接绕过权限验证，把面板服务器上的核心配置文件 config.yaml 给拉下来，从而导致内部密钥彻底泄露。
而且这次大面积被黑的重灾区，大都是开了 WebSSH 的 V1 版本。密钥一旦泄露，攻击者不需要你的 SSH 密码，直接顺藤摸瓜通过探针控制端就能拿到面板下所有小鸡、杜甫的最高控制权，直接一锅端。看群里一次性中招几台十几台小鸡的人大有人在，堪比痛饮哪吒仙饮了。
在这里我真的想狠狠吐槽一下：把服务器的最高权限托管在探针机上，是一个风险极高、极其不明智的选择！
不可否认，哪吒探针的一键 WebSSH 和批量下发命令功能确实是很方便，但这种“方便”在安全面前是不堪一击的。你一个探针，还是主打轻量化的探针，本质就应该是一个轻量化的监测工具，你老老实实收发数据、监控一下 CPU、内存和网络就足够了。
整一堆什么 WebSSH、远程终端、批量命令下发。这些功能本来就不该是一个轻量化探针该做的。很多站长为了图省事，给探针放开了太高的系统权限，一旦作为控制端的面板被攻破，就直接把手里所有服务器的“最高权限”拱手送给了黑客。
如果你的服务器也挂了哪吒探针，建议立刻执行以下操作：
用了哪吒探针的，赶紧去排查一下手里的小鸡吧，最后祝大家的服务器都能平平安安！毕竟服务器运维上，方便虽然也是追求之一，但安全永远是最重要的。
本文 哪吒探针爆致命漏洞（CVE-2026-53519）大批 MJJ 中招！探针就该老老实实做监测好不 最初发表于 秋风于渭水。
2026-06-11 18:01:29
在日常使用浏览器时，我习惯让浏览器自动固定标签页以保持特定页面常驻浏览器，比如用于获取资讯的 RSS 阅读器、监控网页变化的扩展程序，以及日常使用的 Gmail 和工作上必不可少的 OA 系统。然而，原生 Chrome 固定标签页的缺点极其明显：要么容易因快捷键误触导致标签页被“秒关”且无法自动恢复，要么在多窗口或浏览器崩溃重启时无脑重复打开，带来极其蛋疼的体验。
虽然可以把标签页缩小固定在左侧，但一不留神就会误关闭。如果是一般网页还好，浏览器会要求连按两次 Ctrl + W 才能关闭被固定的页面；但对于扩展程序的运行页，只需要按一次 Ctrl + W 就会被无情关闭。再加上我使用了 chrome++ 设置了“双击左键关闭标签页”，误触发关闭的几率直线飙升。此外，固定的标签页在浏览器界面中占用的面积非常小，经常让人无法及时察觉它已被误关。更糟糕的是，有时候浏览器一旦崩溃，所有的固定状态就会荡然无存，不得不手动重新一个个找回并重新固定。
如果设置了启动时自动打开一组网页，弊端同样明显：一旦开启多个新的浏览器窗口，或者在浏览器崩溃后重启时，经常会触发重复加载，导致左侧塞满了一堆一模一样的冗余标签页。我不得不手动一个个去关闭，非常影响日常的使用体验。
面对这些痛点，我的第一反应是寻找现有的解决方案。我一边自己搜索，一边向 AI 求助，在 Chrome 应用商店和 GitHub 上下载了多款扩展进行试用。
然而结果却让人大失所望：市面上的现有工具，要么功能残缺、无法完全满足需求；要么依然停留在即将被淘汰的 Manifest V2 协议，未来随时可能失效；要么就走向了另一个极端——功能繁杂、体积庞大。我其实仅仅需要一个“在后台定时检查并自动拉起被关闭标签页”的简单功能，如果为此去安装一个集成了广告、追踪代码、主题美化、甚至 AI 工作台等一堆捆绑功能的“巨无霸”扩展，严重违背了我的软件哲学：“一款工具最好只专注于做好一件事”。更让人难以接受的是，某些扩展体积臃肿也就罢了，居然还把如此基础的功能列为收费项目，甚至张口就要几十美刀。
既然现成的方案都不尽如人意，且核心逻辑并不算太复杂，那不如自己动手，写一个最纯净、最符合自己需求的工具。
这就是 Smart Tab Pinner 的由来。它是一款专注于浏览器标签页状态维护、100% 本地运行、无任何臃肿依赖的轻量级扩展程序。它原生支持 Manifest V3 协议，在可预见的未来里绝对不会因协议过期而“翻车”。
其实这款扩展我自己已经在日常使用了长达一年之久。经历了多个版本的迭代与打磨后，它现在已经变成了一个非常成熟且稳定的工具。前段时间，有了将那款主打“去 B 站首页推荐算法” 扩展 「TabulaBili-Plus」 成功上架的经验，我决定将「Smart Tab Pinner」也正式开源并提交到 Chrome 应用商店，分享给有同样困扰的朋友。
setInterval定时器在后台闲置时会自动失效。为此，「Smart Tab Pinner」在改为基于 MV3 Service Worker 的持久化设计，利用官方文档推荐的 chrome.alarms API 来替代传统的定时器，从而完美解决了轮询形式的扩展在后台容易休眠的陈年老疾，确保扩展能在后台默默无感且稳定地运行。
具体来说，扩展会在后台定期检查：如果发现用户设定的标签页根本没有被打开，则会自动创建；如果发现匹配的标签页已经打开、但因为误触丢失了固定状态（如果用户勾选了固定选项），扩展绝对不会无脑重复新建，而是会通过 chrome.tabs.update 智能识别最匹配表达式的那一个标签页，直接将其“Up”恢复为固定状态，尽可能解决标签页重复打开的问题。
支持模糊匹配与扩展协议
支持谷歌官方标准的 URL 匹配表达式（例如 https://mail.google.com/*），一个通配符即可完美匹配整个站点的所有子页面。同时，为了满足更极客的需求，它还完美兼容了 chrome-extension:// 协议。也就是说，它甚至可以用来守护其他本地扩展的运行页或设置页（就像前边提到的那样，有些还在用传统的 setInterval 定时器的扩展，需要至少保持打开一个自身页面，以防其内部定时任务失效）。
带沙盒特性的“立即检查”测试
秉承“先测试、后持久化”的原则，我设计了一个“立即检查”按钮。用户在输入框里写完新的配置后，不需要急着点击添加或保存，只需点击“立即检查”，前端就会把这条临时配置发送给后台进行沙盒试运行。只有当用户测试成功、符合预期后，再放心地点击保存，安全感拉满。
极简的交互逻辑
对于已经存在的配置项，点击「修改」按钮后，会自动将现有设置同步至输入区域。用户调整完毕后，只需点击高亮的「确认修改」即可一键保存，完全不需要繁琐地“先删除再重新配置”。
a. 在线安装
1. 「点击一键安装」 或者在 Chrome 应用商店搜索 Smart-Tab-Pinner。
2. 像安装普通扩展程序那样，点击“添加至 Chrome”即可。
b. 本地安装
1. 前往项目的 「GitHub 仓库」，在 Releases 中下载最新版的 smart-tab-pinner-v*.zip 压缩包。
2. 将下载好的压缩包解压到你喜欢的本地目录。
3. 打开 Chrome 浏览器，在地址栏输入 chrome://extensions/ 访问扩展程序管理页。
4. 开启页面右上角的 “开发者模式” 开关。
5. 点击左上角的 “加载已解压的扩展程序”，选择你刚刚解压的本地文件夹，即可完成安装。
安装完成后，点击浏览器右上角的扩展图标，即可进入直观的设置页：
https://mail.google.com/* 或 chrome-extension://deomglgnplnflcbljmehpafdnhdklcep/*）。https://mail.google.com/mail/u/0/#inbox 或 chrome-extension://deomglgnplnflcbljmehpafdnhdklcep/index.html#/）。配置完成后，点击“保存配置”，扩展便会开始在后台默默监视标签页的打开状态。
如果你也和我一样，正在寻找一款纯净、克制、好用的 Chrome 标签页管理扩展，不妨去试试这款 Smart Tab Pinner。觉得好用的话，顺手在商店给个五星好评，或者在 GitHub 上给我点个 Star 鼓励一下，这也是我持续更新的最大动力！
本文 我写了个 Chrome 扩展「Smart Tab Pinner」解决标签页总被误关的问题 最初发表于 秋风于渭水。
2026-06-06 11:06:40
早上习惯性刷 RSS 订阅，看到了宗宗酱发的一篇提醒：你的RSS订阅源有跳菠菜的风险
心里一惊，赶紧翻开自己博客的 Feed 页面扫了一眼。果不其然，根标签里赫然躺着这一行：
wellformedweb.org：黑产是如何盯上 WordPress Feed 的因为是个历史包袱，我就不细说了，你只要知道这个东西是上古时期用来“让读者在RSS阅读器里，能给博客发表评论”用的就行了，这是 RSS 规范的一部分，但这玩意对垃圾评论的防御力几乎是零，所以在十多年前就已经被时代无情淘汰，但没办法啊，为了绝对的向后兼容， WordPress 依然将这行代码原封不动地保留至今。。
最近 wellformedweb.org 域名过期了，就被黑产团伙抢注了。虽然 WordPress 只是把它写在“XML 命名空间”里，WordPress 本身在生成 Feed 时，绝对不会去这个网址下载任何代码。正常 RSS 阅读器也不会去访问这个网址，除非有人直接看你的 Feed 源码，然后手动去点这个网址（能不能点开都两说，毕竟正常情况下此处并不会被渲染为超链接）。
但是云服务商、网管部门、第三方安全插件会无差别提取页面内的所有 URL 链接（哪怕它只是个 xmlns 命名空间里的字符串），这一扫，就发现这个 URL 指向了一个博彩网站，搞不好就直接判定你的网站“包含低俗、赌博等违规内容”，进而触发自动化报警，轻则发邮件警告让你限期整改，重则直接判定违规封禁主域名或IP。
以及不排除未来这个 URL 会进入全球恶意欺诈黑名单，这会导致有些阅读器或者开启了严格安全保护的浏览器，因为探测到你的订阅源含有这个URL，直接给访客弹个“该网站包含危险欺诈内容”的红色标签页警告，这不是纯纯的无妄之灾嘛，所以这行代码最好还是尽早删掉。
看了看网上给出的普遍解法，都是让人“直接去修改 wp-includes/Feed-rss2.php 文件，删掉这一行”。
这就有点不够优雅了，动系统文件向来是慎之又慎的事情。一个不小心直接改炸了不说，而且一旦 WordPress 升级，修改搞不好就被直接覆盖了，属于治标不治本。
那既然不打算动核心文件，那就只能考虑动态移除。最显而易见的修改方案有两个：
所以我决定用 PHP 搞定问题。跑去问了下 AI 这个标签的钩子是啥。结果 AI 一摊手：硬编码，没钩子。
啊，这……行吧，既然你不给钩子，那就别怪我直接对输出缓冲区下手了。
在 Code Snippets 插件中新建一个代码段（选择在所有位置运行），或者写到你当前主题的 functions.php 文件中也行。利用 PHP 的 ob_start 在页面渲染完成、输出前的最后一刻，把这个 URL 给滤掉。
PS：更新，经评论区提醒，WordPress不仅会在 RSS 订阅源开头声明 wfw ，在后面每篇文章的结尾还有生成RSS评论区的代码：<wfw:commentRss>https://XXXXXX/feed</wfw:commentRss>。这部分也需要同步去除，不然只移除开头的命名空间，而不移除每篇文章的RSS评论区。 RSS 阅读器会一脸雾水，哪来的wfw啊，导致报错。
代码如下：
/**
* 移除 WordPress RSS2 中的 CommentAPI 命名空间及相关标签
*/
add_action('template_redirect', 'perfect_clean_rss2_buffer', 0);
function perfect_clean_rss2_buffer() {
// 仅对 RSS2 订阅源生效
if (is_feed('rss2')) {
ob_start('rss2_namespace_cleaner');
}
}
function rss2_namespace_cleaner($buffer) {
// 1. 匹配并移除开头的命名空间声明
$search_pattern = '/xmlns:wfw="http:\/\/wellformedweb\.org\/CommentAPI\/?"\s*/i';
$buffer = preg_replace($search_pattern, '', $buffer);
// 2. 匹配并移除每篇文章下的 <wfw:commentRss> 标签
$comment_pattern = '/<wfw:commentRss>.*?<\/wfw:commentRss>\s*/i';
$buffer = preg_replace($comment_pattern, '', $buffer);
return $buffer;
}
小提示：保存并启用代码后，如果刷新页面没变化，八成是有什么东西给你的Feed做了缓存，记得去后台刷新一下你的站点缓存
如果你不想动 PHP，且你的 Nginx 编译了 sub_filter 模块，也可以直接在 Nginx 配置文件中加入以下规则动态替换：（让AI写的，我没实际测试过）
location ~* /Feed/?$ {
sub_filter '' '';
sub_filter_once off;
sub_filter_types application/rss+xml text/xml;
try_files $uri $uri/ /index.php?$args;
}
不得不感叹一句，最近黑产真的越来越钟情于这种“历史遗留域名过期被恶意抢注（内容劫持）”的连带攻击方式了。
他们利用了对老域名的盲目信任，不需要入侵你的服务器，就能白嫖全球无数独立博客的连带流量和权重，不可谓不鸡贼。在 WordPress 官方正式移除这行代码之前，建议各位站长，赶紧去排查并手动移除自己的 /feed 隐患
2026-05-27 10:42:06
前几天，我重构魔改后的扩展 TabulaBili-Plus 正式通过了谷歌严苛的 MV3 审计，在 Chrome 应用商店成功上架。原本看着后台不断增长的活跃用户数还挺开心的，结果前天点开评价区，发现迎来了一个一星评价。
这位朋友言辞有些激烈，大意是说我“山寨上游项目，有能力改了项目 bug 却不给原作者提 PR 修复，反而改个相似的名字上架商店，是在搞开源社区的分裂，是在山寨，没遵守原作者的要求在 UI 里保留他的博客”。
看到这个评价，我脑子里闪过的全是以前吃开源社区各种“二开、另立门户、互撕”大瓜的画面，万万没想到，这次自己成了瓜里的主角😂。虽然能感受到这位老哥对开源生态的热心，但他可能平时看热闹居多，对开源协议和协作体系还缺乏深入了解。他既没有耐心读完长篇的项目介绍，也没注意到我在 GitHub 和文章评论区里与原作者的互动，甚至连扩展的 UI 界面都没仔细看——不然他就会发现，UI里「🌟灵感来源」按钮正链接着原作者的博客。他自以为是在维护正统的“开源正义”，却因为对现代开源社区的运作机制认知不全，直接血气上涌，A 了上来。
首先声明一下，我今天写这篇文章，绝对不是为了挂人或指责这位老哥（我向来不喜欢网络暴力和挂人，请大家权当看个趣闻，切勿寻找这位朋友）。相反，他给我送来了一个绝佳的博客选题：在看似自由的开源世界里，到底怎么做才算既符合开源协议的规则、又符合开源圈子的人情世故？
借着这个由头，科普一下：常见的开源协议是什么？如何正确地 Fork 二开？二开和原作者的责任边界在哪里？当你为自己的项目选择某个开源协议时，当你将软件推向泛大众使用时，你到底得到了什么，又放弃了什么？
那堆密密麻麻、翻译得像绕口令一样的开源协议文本，让人一看就头大。所以我就不干巴巴地列举条文了，而是用开发者对待项目的心态来做分节标题。方便大家写完工具准备开源时，只需要对照自己属于哪种心态，就能直接对号入座：
MIT 协议TabulaBili-Plus）、原项目（TabulaBili）、Vue、React。GPL 协议（GPL v2 / GPL v3）Linux 内核、Git、WordPress。💡 小科普：GPL v2、v3 和 AGPL 之间到底有什么区别？
- GPL v2 的漏洞（以 TiVo 化为例）：当年机顶盒厂商 TiVo 非常遵守
GPL v2，大方开源了自己魔改的 Linux 内核。你确实能自由下载和修改代码，但当你把改好的固件刷回机顶盒时，硬件会检测数字签名，不是官方签名直接拒绝开机。 代码表面上开源了，但用户其实改不了一点，硬件直接锁死，形同虚设。- GPL v3 的反击：自由软件基金会（FSF）被这种“合规不合理”的行为激怒了。于是在
GPL v3中规定：如果你的硬件运行了GPL v3软件并面向消费者，你必须无条件提供修改该软件并使其在硬件上运行所需的全部密钥和数字签名。这也是为什么 Linux 之父 Linus 坚定让 Linux 留在 v2，而大厂对 v3 十分抗拒的原因。（比如最近拓竹的核心切片软件Bambu Studio，由于 Fork 自PrusaSlicer，其内部的bambu_networking模块却闭源，且作为软件与硬件正常运行中不可或缺的核心组件被强制捆绑，因而惹上了官司，深陷开源合规的舆论风波。）- 专利防御：
GPL v3还自带“专利反击盾”，规定任何贡献代码的人视同自动向后续用户授予相关专利使用权，防止有大厂玩“先开源项目、之后反手告用户专利侵权”的流氓套路。- 违规宽限期：
GPL v3拥有 30 天的“违规宽限缓刑期”，比 v2 的“一违规立刻永久剥夺授权”要温和得多。比如二开时不小心在 License 里写错了原作者的名字，在 v2 下你会被立刻永久剥夺授权，而在 v3 下你只要在被提醒后的 30 天内补上就行。- GPL 的漏洞与 AGPL 的反击：根据 GPL 的要求，当用户获得你的程序时，你必须让他们能够获得源码。但这并不代表你必须“无偿”提供程序本身（比如红帽 Red Hat）。其次，把 GPL 软件部署在自己的服务器上，通过网络接口给用户提供服务的话，因为根本没有把软件“分发”到用户的电脑里，就能完美绕过了 GPL 的开源约束。AGPL 专门堵的就是网络服务这个场景漏洞。
Apache 2.0 协议Android、TensorFlow、Apache。MIT 多了一层极其严密的官方专利授权保护条款：谁要是给项目贡献了代码，就视同他自动免费授权了贡献部分的专利使用权；同时它明确保护了作者的商标和专利，是很多商业大厂的首选。BSD 协议Go、Python、Nginx、PostgreSQL、React（早期）。BSD 和 MIT 非常相似，但它比 MIT 更在乎“名誉和责任”。BSD 多了一条“铁律”——绝对不允许用原作者或者原项目的名字来给你的衍生产品做商业背书或打广告（除非得到书面许可）。这就叫“二开归二开，各凭本事，别蹭劳资名气”。很多知名的独立开发者和开源组织会选择这个协议，以防品牌被滥用。| 开源协议 | 是否允许闭源/商业化 | 是否必须保留原作者署名 | 是否有严密的专利保护条款 | 是否允许二开带有原项目/作者名 | 核心特征描述 |
|---|---|---|---|---|---|
| MIT | 允许 （最佛系自由） |
必须保留 | 否 (仅提供基础免责护甲) |
允许 （拥有修改和更名权） |
“你爱咋用咋用，保留署名、出事别找我” |
| GPL | 绝对不允许 （强传染性） |
必须保留 | 是 （GPL v3 自带专利反击盾并防硬件锁死） |
允许 （但衍生项目必须无条件向全网开源） |
“谁也别想白嫖去闭源，沾上就必须开源” |
| Apache 2.0 | 允许 （最适合商业化） |
必须保留 | 是 （提供极其严密的官方专利授权保护） |
明确保护作者的商标与专利，不可滥用 | “可以商用，但谁贡献谁就得自动免费授权专利” |
| BSD | 允许 | 必须保留 （且修改文件必须写声明） |
否 | 严厉禁止 （除非得到明确许可） |
“二开归二开，各凭本事，绝对不准蹭劳资名气” |
回到开头那位老哥的指责：“改个相似的名字上架，是在搞山寨和破坏开源精神”。这恰恰暴露了他对开源世界中“责任划分”与“人情世故”的认知模糊。
原作者在 GitHub 仓库采用的是最自由的 MIT 协议。这意味着在法律层面上，任何人完全拥有修改、更名和独立分发的权利，无论下游用，亦或不用原项目的名字，都是完全合规的。但比合规更重要的，是现代协作中的“责任隔离”。
在这次重构中，为了解决极端弱网、冷启动以及状态同步等一系列边界坑，我引入了新的 content.js 自动化脚本、MutationObserver 弱网防误刷新机制、以及本地 Storage 状态持久化。虽然核心的 DHR 机制和界面几乎没变，但上层的运行机制、权限和逻辑已经被我魔改了一大半（从代码量评估，基本上是从 100 行扩展到了 200 行）。
如果我不改名字，还厚着脸皮叫原名 TabulaBili 往商店一扔，UI 里还用大字链接到原作者的仓库和博客，一旦 B 站将来大改版导致页面白屏或功能失效，成百上千根本不懂技术的普通用户，就会顺着这个名字摸到原作者的个人博客和 GitHub 仓库下面，给原作者的留言板和 Issues 区添堵、催更甚至责骂。 这对于本想安安静静写点代码、明确在 README 里声明了“没有上架应用商店计划”的原作者来说，简直是无妄之灾。这也是为什么我第一次尝试用原名上架谷歌商店时会被官方直接打回。因为在应用商店的规则里，二开项目不改名，反倒有可能会被判定为恶意仿冒和混淆的违规行为。
改名为 TabulaBili-Plus，在扩展界面底部感谢原作者的灵感，在项目介绍、商店介绍里全都特意致敬原作者，同时把反馈链接改到我自己的仓库——把所有因为二开带来的 Bug、吐槽和维护售后等“杂七杂八”的事务全揽在自己身上，把纯粹的感谢留给原作者。这不仅不叫分裂，反而是一种“责任切割”。 我发布的版本我来负责，大家可以去给原项目点 Star、留言感谢原作者的创意，但别因为我的二开中的错误去打扰原作者的清净。
虽然在 MIT 协议下，法律并不强求在扩展 UI 内保留作者博客信息，但本着开源圈子的“人情世故”，我依然认为应该在不让用户产生混淆的前提下，尽可能在推广和介绍里保证有致谢原作者的部分。
那位老哥另外执着的一点在于：“你既然改了 bug，为什么不给原作者提 PR 修复，非要自己独立搞一套？”
其实，提不提 PR（Pull Request），在软件工程里有着非常严密的逻辑边界。
以 TabulaBili 为例，原作者在 README 中表达得非常清晰：保持极致的轻量，不需要常驻后台进程，也不想在页面注入复杂 DOM。而我的 Plus 版为了彻底解决 B 站首屏 SSR 的推荐直出问题，必须引入 Content Script、MutationObserver 和 Storage 权限，往 B 站首页注入了脚本。
这就像我最近在魔改一个关于 GPT-image2.0 绘图的项目，为了让同事们能在工作中开箱即用，我加入了“后端内置 API KEY”和“后端内置图片反代”两个功能。而这两个设计，是原作者在 Issues 相关讨论中明确表示反对的。
如果我把这种与原项目设计理念明确冲突的代码打包成 PR 强行塞给原作者，无异于在逼着原作者去审核他本来就不想要的东西、如果他合并了，未来就为一部分他本不想要的代码承担未来的维护责任。这不叫开源奉献，这叫对原作者精力的道德绑架。
如果真的感觉自己的 PR 很有意义，但和项目现有理念冲突了，感觉最好还是先提个 issues 问问维护者的意见，直接一个 PR 怼上去就有点冒犯了，除非项目本身就建议直接提 PR。
至于老哥指责的“不给原作者提 PR”，事实上，我不仅提了 PR ，而且在重构之初就提交了。
在不破坏原作者核心架构、且对原项目有益的通用改动上（比如对域名过滤逻辑的优化、对界面文字排版重叠的修复），我早已向上游提交了代码。但开源作者的精力和时间都是有限的，上游作者由于生活工作忙碌没有合并，或者主观上不想合并，这在开源世界里都是再正常不过的常态。我们不能躺在地上死等对方合并，或者无休止地去催促对方，“自己动手，丰衣足食”才是真正的开源效率。
PS：当然，如果一个有很多用户的项目，存在重大安全漏洞（比如最近经常发生的供应链攻击），那该催的时候也要催。
一个开发者，把自己的代码锁在本地自用、放到 GitHub 默默开源，以及将其包装后推向大众，这三者之间到底有着怎样的“得与失”？
在代码只属于自己的时候，是最自由的。代码写得再烂、逻辑再脏、全是硬编码的 API Key，都无所谓，只要能跑通就行。不需要考虑极端场景触发bug，因为可以注意不去触发，不需要写长篇的 README，只要适当留下注释能让未来的自己看懂就行，更不用去理会谷歌那严苛到掉头发的 MV3 审核，开发者模式下根本没人管你申请什么权限。这是最纯粹的效率，但代价是，自己的作品永远只是一个孤芳自赏的局部工具。
当你把代码上传到 GitHub，代码就有了生命。在这个阶段，你的受众主要是同行或折腾能力较强的极客。他们看得懂源码，能通过 Issues 给出建设性的 Bug 反馈，甚至会直接给你提 PR 帮你修代码。在这个阶段，开源是快乐的，圈子是小而精的，信息熵极高且充满善意。平台自身的门槛阻止了大部分低质量的讨论，虽然也有一些争吵，但基本都是互相摆证据的论述。但你的软件还是被局限在一个不太的的圈子里，除非你的项目能被大厂盯上，但大厂又九成会直接抄走不谢。
一旦你决定将它“彻底推向大众”，事情的性质就完全变了。
把代码放出来是“利他”的分享，但把它包装好推给大众，则是一场用个体精力去对抗系统复杂性的修行。你获得了影响力、技术成长甚至一些利益的同时，就必须让渡一部分清净，去接纳那些不那么完美的反馈。
以TabulaBili-Plus为例，这个扩展的上架后
回到最初的起点。既然把代码包装好推向大众需要经历这样的“修行”，那为什么我们依然对开源乐此不疲？
因为开源的魅力，恰恰在于基于规则和协议之上的“野蛮生长”与“无限可能”。如果没有人愿意分享，开源世界只是一片死水；而如果所有人分享后都选择偏安一隅、拒绝破圈，那好项目就永远无法惠及大众。
在这场协作里，原作者 @wangdaodao 凭借敏锐的直觉给出了极其优秀的底层拦截灵感，我遵循 MIT 协议接过接力棒，在此基础上完成了商店应用的工程化落地。这种“前人栽树，后人改造，各司其职，责任自负”的交接，正是开源最迷人的地方。（原作者 wangdaodao 做出了 TabulaBili ，在此基础上有了 TabulaBili-Plus，在Plus的基础上，又诞生了Firefox的TabulaBiliFirefox；还诞生了B站三方客户端 BiliPai 的插件，一个灵感就衍生出了至少4个开源项目）。
代码是自由的，协议是严肃的，责任是明确的，而人情世故是有温度的。开源社区从来不是靠在键盘上扣“正统”和“三方”的帽子发展起来的，而是靠一行行合规、合理、互相尊重的代码堆叠起来的。
最后，还是要再次感谢那位打一星的老哥。谢谢你用一个刺眼的差评，送给了我一个绝佳的文章选题，让我能和大家聊聊这些关于开源、规则与成长的小话题。
本文 别用“开源正义”道德绑架了！聊聊二次开发的开源协议、责任边界、人情世故 最初发表于 秋风于渭水。
2026-05-23 10:07:16
麻了已经，毁灭吧，赶紧的，要是安卓也能这么容易拿到 root 就好了，可惜这 5 个漏洞貌似对安卓都无效
好消息：目前除了Linux 第5漏洞： 「PinTheft」 暂时没补丁，其他都已经修复了，正常更新就可以打上补丁
坏消息： 估计有些前两天刚把集群的 Nginx 升级到1.31.0/1.30.1的运维，又要周末加班了。
# Ubuntu, Debian
sudo apt update && sudo apt upgrade -y
# Rocky, Alma, RHEL
sudo dnf upgrade --security -y
# Alpine
apk update && apk upgrade
sudo apt update && sudo apt --only-upgrade install nginx -y
# 进入你的 LNMP 安装包目录（以你下载的版本号为准）
cd /root/lnmp2.0/
# 运行升级脚本，指定升级目标为 nginx
sudo ./upgrade.sh nginx
# 脚本会告诉你现在的版本，并问你要升级到什么版本，正常输入稳定版的版本号就行，比如目前是1.30.2
Current Nginx Version: 1.30.1
Please input next Nginx Version: 1.30.2
# 哦，对了，如果你有第三方模块记得提前改`lnmp.conf`
