zhihu-web-enhancer 是我基于 X.I.U“知乎增强”维护的非官方衍生版：保留原脚本常用的内容过滤与网页增强能力，同时把关键词过滤扩展到了知乎“等你来答”的全部问题分类。项目仍处于早期试用阶段，适合愿意检查源码、手动迁移配置并反馈兼容问题的 Tampermonkey 用户。

为什么做一个维护版

“知乎增强”已经能按用户、关键词、内容类别、赞同数和评论数过滤内容，也提供收起回答、清理登录弹窗、显示完整时间、使用原图和处理站外直链等实用功能。

建立衍生维护版还有一个更现实的背景：原作者 XIU2 已经明确调整了上游脚本的维护方向。2026-02-26，他在功能请求 #574 中说明脚本已进入维护期，非必要功能原则上不再增加；2026-07-30，他又在功能请求 #597 中重申这一点，并说明当前主要精力是维护已有功能。

这不代表原版已经停止维护：现有功能修复和必要适配仍可能继续，只是新增功能不再是上游重点。对仍在深度使用知乎、又有具体页面适配需求的用户来说，建立独立衍生版比持续向上游提出超出当前维护范围的功能请求更合适，也能把功能边界、验证责任和后续更新留在自己的仓库中。

但在我的实际使用中，“屏蔽指定关键词”没有覆盖 /question/waiting，也就是“等你来答”页面。这里的“为你推荐”“邀请回答”“最新问题”和“人气问题”共用一套问题列表，却不能沿用已有屏蔽词过滤。结果是：同一组关键词在普通信息流里有效，进入“等你来答”后又会看到本来想避开的题目。

与其另写一份重复维护屏蔽词和设置界面的补丁，我选择从上游脚本建立一个独立维护版，继续复用原有菜单、存储键和匹配语义，只为缺失的页面补 Adapter。

项目地址：Onlydreams/zhihu-web-enhancer

它新增了什么

当前维护版脚本版本为 2.3.35，基于上游 2.3.32。首个衍生功能专门补齐“等你来答”的关键词过滤：

  • 覆盖“为你推荐”“邀请回答”“最新问题”和“人气问题”四个分类；
  • 直接复用原有“屏蔽指定关键词”开关和自定义关键词列表；
  • 按既有规则规范化空白并进行不区分大小写的匹配；
  • 检查问题标题，命中后隐藏完整问题卡片；
  • 同时处理首屏列表、滚动后的动态加载内容和 SPA 首次进入页面；
  • 关闭关键词过滤后，不再继续隐藏新加载的问题。

这里的“屏蔽”只改变本地页面显示。脚本不会替你点击“不感兴趣”，不会向知乎提交推荐反馈，也没有为这个功能新增知乎 API 调用或额外网络请求。

不只增加功能，也处理使用中的毛刺

维护版还对继承实现做了几处小范围硬化：

  • 在问题页首次绘制前，根据现有用户黑名单生成本地 CSS，尽量减少被屏蔽回答先出现、随后再消失的闪动；
  • 给首批元素等待设置明确的检查间隔和停止上限，避免页面结构变化后无休止轮询；
  • MutationObserver 遇到文本节点时，不会跳过同批次后续需要处理的元素；
  • 收起回答的观察器在 SPA 页面往返后可以重新启动；
  • 站外直链只接受有效的 HTTP/HTTPS 目标，畸形地址或其他协议保持原样。

这些改动没有把项目变成新的框架。仓库仍然只有一个主 Userscript 文件，零构建、零运行时依赖，便于直接审查、安装和与上游比较差异。

它和另外两个知乎脚本是什么关系

项目 主要职责 是否需要同时启用
原版“知乎增强” 上游官方维护版本 迁移到本维护版后应停用，避免重复处理页面
zhihu-web-enhancer 保留上游能力，并维护个人需要的页面适配 作为原版“知乎增强”的替代版本使用
zhihu-action-width-fix 修正“知乎美化”与增强脚本叠加后的操作栏布局 只有遇到对应 UI 错位时才需要

新名称和 namespace 会让 Tampermonkey 把维护版识别为独立脚本，因此它不会直接覆盖原版。不过，两个增强脚本同时启用会重复监听和修改同一个页面，迁移完成后应只保留一个处于启用状态。

如果你使用“知乎美化”后还遇到操作栏宽度或搜索页布局错位，可以再看《知乎美化/知乎增强本地 Fix：修正操作栏与搜索页错位》。那是独立的 UI 补丁，不属于本维护版的内容过滤功能。

后续计划：建立“知乎美化”衍生维护版

“知乎美化”与“知乎增强”由同一作者维护，也位于同一个 XIU2/UserScript 仓库。既然“知乎增强”已经通过独立衍生版承接个人需要的功能补充，后续也计划用相同方式为“知乎美化”建立非官方衍生维护版。

届时会考虑把当前独立运行的 zhihu-action-width-fix 合并进去。它目前负责修正“知乎美化”与增强脚本叠加后，推荐流、搜索结果和想法卡片中的操作栏宽度、fixed 定位及嵌套按钮错位。把这些逻辑放回“知乎美化”的衍生维护层，可以减少需要同时安装的脚本数量，也让样式规则、页面适配和版本兼容由一个项目统一负责。

这项工作目前只是后续计划，不代表新的“知乎美化”维护版已经建立，也不代表现有 Fix 即将停止更新。正式合并前至少需要完成：

  1. 以“知乎美化”最新上游版本和 commit 建立可追溯的原始基线；
  2. 区分上游样式、本地布局修复与真正需要长期维护的衍生能力；
  3. 将 zhihu-action-width-fix 的回归测试和页面验证场景迁入新仓库；
  4. 复测推荐流折叠/展开、fixed 操作栏、搜索结果和个人主页想法等关键页面；
  5. 提供清晰的安装与迁移说明，确认新维护版能够替代原版“知乎美化”加独立 Fix 的组合后，再考虑停止独立分发 Fix。

在这些条件满足之前，zhihu-action-width-fix 仍是独立项目，现有用户不需要提前迁移。

安装前先看清当前阶段

这个项目目前还没有作为独立稳定发行版发布，main 分支更接近可审查、可试用的维护版本。脚本头部没有显式设置 @updateURL 或 @downloadURL；Tampermonkey 官方同时支持从 GitHub Raw 页面安装 Userscript，但本文尚未核验 Raw 安装和手工粘贴两种方式的后续自动更新行为。升级前应先比较仓库中的 @version 和源码；通过编辑器手工粘贴安装的用户，需要自行覆盖旧源码。

如果你接受这个边界，可以按下面的方式试用：

  1. 先保留并启用原版“知乎增强”，不要急着删除。
  2. 在原版菜单中打开“自定义屏蔽用户”，全选并复制完整内容，然后点“取消”。如果看不到该菜单，先记录“屏蔽指定用户”的当前状态，临时启用它并刷新页面后再复制。
  3. 用同样的方法复制“自定义屏蔽关键词”；如果菜单不存在，先记录并临时启用“屏蔽指定关键词”，刷新后再操作。关键词之间的 | 分隔符需要保留。
  4. 记录原版其他功能开关，以及“屏蔽低赞低评”“屏蔽指定类别”中的自定义选项。
  5. 停用原版“知乎增强”，但暂时不要删除，把它保留为配置备份。
  6. 检查维护版 Zhihu-Enhanced.user.js 的 Userscript 头部与源码，再通过 Raw 页面 安装；如果浏览器没有自动唤起 Tampermonkey，就新建脚本并完整粘贴源码。
  7. 在维护版菜单中分别粘贴屏蔽用户和关键词；如果对应菜单没有出现，先启用相关屏蔽开关并刷新。随后按记录恢复其他开关、数值及原来的启用状态。
  8. 刷新知乎，检查普通信息流以及“等你来答”的四个分类；确认无误后，再决定是否删除原版。

两个脚本的 namespace 不同，所以原版 GM_* 配置不会自动复制，维护版也不能直接读取原版配置。迁移期间保留已停用的原版，可以把它当作配置备份；确认没有遗漏后，再决定是否删除。

适合谁，不适合谁

这个维护版更适合以下用户：

  • 已经在使用“知乎增强”，并依赖用户、关键词或类别过滤；
  • 经常浏览“等你来答”，希望四个分类使用同一套关键词规则；
  • 能接受手动迁移一次配置，并愿意在知乎改版后反馈兼容问题；
  • 希望过滤只发生在本地，不自动向平台提交账号操作或推荐反馈。

如果你只需要上游已有功能、不访问“等你来答”，继续使用原版通常更省心。如果你期待应用商店式的稳定发布、自动更新和跨版本配置迁移，也建议等维护版完成更多真实页面验证后再安装。

当前验证范围

截至 2026-08-08，我对仓库当前脚本运行了：

真实页面证据来自本地浏览器与 Tampermonkey 中持续一段时间的实际使用和功能复核；当时没有记录浏览器及 Tampermonkey 的精确版本，因此“当前可用”只覆盖这次本地使用结论，不扩展为所有浏览器版本均已验证。

自动化检查在 Windows Node.js 环境中执行：

node --check .\Zhihu-Enhanced.user.js
node --test

语法检查通过，14 项源码测试全部通过。测试覆盖独立脚本身份、关键词规范化与匹配、四分类共用过滤范围、问题卡隐藏与恢复、动态新增内容、首屏屏蔽样式，以及几项上游实现硬化。

这些自动化结果证明当前源码满足仓库内的可执行约束，但不能代替知乎真实页面验证。当前 2.3.35 已在本地 Tampermonkey 环境中持续使用一段时间，并完成核心功能复核，因此文章状态标记为“当前可用”。这份结论只覆盖本地实际使用环境，不代表知乎后续改版后无需重新验证。

源码、反馈与许可证

维护版继续使用 GPL-3.0，保留原作者 X.I.U 的署名与来源说明；它是非官方衍生项目，与原作者没有隶属或代表关系。

如果你试用了“等你来答”关键词过滤，最有价值的反馈不是一句“能用”或“不能用”，而是具体说明分类、进入路径、是否经过 SPA 跳转、是否发生懒加载，以及命中问题卡的 DOM 变化。这样的复现信息才能真正帮助维护版跟上知乎页面调整。