起因很简单：我想多看一些文章。

不是被信息流推着刷，而是自己挑一些值得读的源，攒起来慢慢看。RSS 恰好就是这个形态——没人给我排序，也没有推荐算法替我决定该看什么，读到什么完全取决于我订阅了谁。

于是我开始找客户端。我主要用 Windows，试过一圈之后发现选择相当尴尬：

• 网页版：打开慢，切个标签页就找不着了，还要看服务商什么时候关站。
• 在线服务：数据在别人服务器上，隐私且不说，免费额度、导出限制、突然改版都是变量。
• 老牌桌面客户端：功能其实够用，但界面停留在十年前，高分屏下字体发虚，装完先弹广告或者引导你买 Pro。
• Electron 系：装完先吃掉 300 MB 内存，冷启动能看见窗口一帧帧画出来。

我不要求它有多花哨。我的需求清单其实很短：

1. 订阅源和阅读状态存在本机，不上传；
2. 启动要快，常驻内存别太夸张；
3. 中文排版能看，浅色 / 深色跟随系统；
4. 支持 OPML 导入导出，别把我锁死；
5. 图片能正常显示——这点后面成了最大的坑。

找了几天没找到满意的，索性自己写。于是有了 ++RSS Reader++。

技术选型：为什么是 Tauri 2

选 Tauri 而不是 Electron，核心就一条：我不需要一个完整的 Chromium。

Windows 上 WebView2 是系统自带的（Win11 内置，Win10 装一次），Tauri 直接复用，安装包和内存占用都能压下来。代价是三个平台的 WebView 内核不同，遇到怪问题时得自己扛——但对我这种「自己用的工具」来说，这个交易划算。

分工也很清晰：

有一条设计原则贯穿全程：状态的权威在 Rust 侧。订阅源、文章、分组都落在 app_data_dir/state.json，前端只是视图。主题、字号、抓取频率这些纯展示偏好才放 localStorage。这样窗口关掉再开，数据一定是对的；前端崩了也不会把数据写坏。

几个真正花时间的坑

功能列表写起来一行，做起来是另一回事。下面这几件事占了我大部分调试时间，也最值得记下来。

1. 图片：防盗链、混合内容与一条重试阶梯

RSS 里的图片看起来是 <img src="..."> 这么简单，实际上一半显示不出来：

• 图床校验 Referer，空 Referer 放行、带错 Referer 就 403；
• 正文里是 http:// 图片，在 WebView 里被混合内容策略拦掉；
• GitHub Pages 上的图片没跟着发布，原地址恒为 404；
• 图床按 IP 限流。

最后的方案是本地注册一个 rssimg:// 协议，所有文章图片都走它，由 Rust 侧带浏览器 User-Agent 去抓。抓取按阶梯来：

1. 先直连、不带 Referer（多数防盗链对空 Referer 是放行的）；
2. 遇到 403 就补上文章页的 Referer 重试，并把这个图床记进一个集合——下次同一图床的第一个请求直接带 Referer，省掉一次注定失败的往返；
3. 还失败就回退直连再试一次；
4. GitHub Pages 的图片额外生成 cdn.jsdelivr.net 镜像候选。这里有个细节：镜像优先走当前链路（国内直连 cdn.jsdelivr.net 经常不通），失败后才退直连。

成功响应缓存 7 天，单张上限 50 MB，只放行 http / https。

顺带一个工程上的小坑：rssimg:// 是自定义 URI scheme，不走 IPC，所以它拿不到命令参数上下文。应用里的代理配置得靠 update_proxy_setting 先同步到 Rust 的全局状态，图片代理才读得到。这种「看起来是一件事、实际跨了两条通道」的地方，最容易漏。

2. 写盘：临时文件 + 原子改名

用户点一下「标记已读」，就可能要写盘。直接 fs::write 有风险：写到一半断电，state.json 就成了半截 JSON，下次启动数据全丢。

做法是写临时文件再 rename。而 Windows 上 rename 在目标被占用时会失败，所以失败后要小睡一下重试一次。这类平台差异，文档里通常只有一句话，踩到了才知道。

另一半是频率。标记已读、收藏、排序都是高频操作，每次都落盘会把磁盘打满。所以走 800 ms 防抖合并，窗口隐藏或关闭前强制 flush 一次——既省 IO，也不会丢最后一次操作。

3. WebView 里的整页跳转和右键菜单

这两个是我自己用的时候最先受不了的：

• 文章里点个链接，WebView 直接整页跳转，自定义标题栏被外部网页盖住，回不来了；
• 右键弹出的是 WebView 自带的 Back / Refresh / Save as / Print 菜单，一股「这是个浏览器」的味道。

修法是加全局守卫：<a> 的点击一律 preventDefault，http(s) 交给系统默认浏览器打开，只放行页内锚点；中键点击也拦掉，因为应用没有多窗口 UI。相对链接要靠正文容器上的 data-link-base 解析——文章原始地址才是正确的基准，不能拿应用自己的 origin 去凑。

右键菜单则整体屏蔽，但文本输入框要放行，否则搜索框里连粘贴都用不了。第一版就是一刀切，被自己骂了一顿才补上的。

4. 图标字体：5 MB 变 37 KB

界面用 Material Symbols Rounded。完整可变字体 5 MB 出头，而我实际只用了 40 多个图标，为了这几十个字形背 5 MB 显然不划算。

于是写了个子集化脚本：从源码里扫出用到的图标名 → 下载完整字体 → 按清单子集化 → 用 HarfBuzz 逐个校验连字可用性 → 写回 woff2。最终 37 KB，还不依赖 Google CDN。

代价是新增图标后必须重跑脚本，否则界面上会直接显示成文字（比如按钮上写着 search）。这个坑我在 README 的常见问题里专门写了一条。

5. 自动更新：签名、双源与回退

0.2.0 加了应用内更新。几个我觉得不能省的点：

• minisign 签名，公钥内置在应用里，签名校验不过就拒绝安装。私钥丢了就再也发不出老用户能装的更新，所以必须单独备份；
• 更新清单优先取 GitHub Releases，失败自动回退 Forgejo Releases——两边各托管一份 latest.json，各指向自己的资源；
• 应用内配的代理一并用于更新请求；
• Windows 走 NSIS 安装器的 passive 模式，装完自动重启。

现在它长什么样

两栏布局：左边文章列表，右边阅读视图，中间分隔条可拖拽调宽（宽度会记住）。

• 订阅管理：RSS 2.0 / 1.0、Atom、JSON Feed；分组折叠与未读数；OPML 导入导出；单个源可选应用内阅读或外部浏览器打开
• 抓取：ETag / Last-Modified 条件请求（304 直接跳过下载与解析），并发上限 6，自动刷新间隔 10 分钟到 1 小时可选
• 阅读：全部 / 未读 / 收藏筛选，最新 / 最早 / 按源排序，紧凑 / 列表 / 卡片三种视图，标题 + 正文全文搜索，大列表首屏 300 篇、滚动加载更多
• 全文：摘要过短时一键抓原文，正文容器启发式提取并清理广告 / 评论 / 侧栏，最近 20 篇缓存复用
• 数据：JSON 备份 / 还原，按发布时间清理本地缓存（星标保留）
• 网络：HTTP / SOCKS5 代理，一键连通性测试（多探测目标，避免单站误报），SOCKS5 走 socks5h 让代理解析域名
• 安全：最小权限 capabilities、严格 CSP、正文渲染前移除 script / iframe / form / base 等节点

当前版本 0.2.1，Apache-2.0 授权，Windows x64 有现成安装包（NSIS / MSI / 免安装单文件），macOS 和 Linux 需要自己编译。

不足的地方，我很清楚

写着写着就明白为什么这类工具少有人做了——坑太多，而每个坑都要单独填。下面是目前已知的问题，我不打算藏：

• 正文提取只是启发式。没上 Readability 级别的评分算法，容器选择器 + 无关元素移除在不同站点效果差异明显，有些站抓出来还是会缺段落或者多塞东西。
• 正文渲染不做完整 HTML 白名单净化。为了保住排版只做节点清理，因此只适合可信订阅源。这是明确的安全取舍，不是疏忽。
• 没有云端同步。多设备迁移只能靠备份 / 还原或 OPML，计划里的 WebDAV 备份还没做。
• 跨平台没验证。bundle.targets = all 也只打包当前平台，macOS / Linux 我没机器实测，只能保证代码层面没写死 Windows。
• 翻译功能没做，外文源只能自己看原文。
• 早期阶段。0.2.1 还在快速变动，state.json 的结构虽然带 schema_version 和迁移逻辑，但不保证百分百兼容。

所以，欢迎提 Issue

我写它的直接原因就是「自己没找到好用的」，那就意味着你觉得别扭的地方，多半我也没考虑到。不管是 bug、界面建议、还是「这个源解析出来是乱的」，都欢迎开 issue：

• GitHub：++https://github.com/z1HwanG/RSS-Reader/issues++
• Forgejo：++https://git.z1hwang.cn/Zeehow/RSS-Reader/issues++
• 应用内：设置 → 关于 也有直达入口

想让 issue 好处理一点，附上这些会省很多来回：

1. 复现步骤：点了什么、期望什么、实际什么；
2. 订阅源地址（如果和某个源有关）——解析问题九成要拿原始 XML 复现；
3. 界面问题直接截图，比文字描述快十倍；
4. 出错的图 / 文章链接，图片问题基本都要看具体响应；
5. 版本号（设置 → 关于里有）。

Pull Request 同样欢迎。提交前跑一下 npm run build（TypeScript strict + Vite 构建），改了 Rust 建议再过一遍 cargo fmt 和 cargo clippy --all-targets。

最后

做这个小工具最大的收获，是重新意识到「能用」和「好用」之间的距离有多远：抓取解析一两天就通了，但防盗链、原子写盘、WebView 跳转、图标子集化这些看起来边缘的细节，才真正决定你愿不愿意每天打开它。

它现在还不完美，但我自己就是它的第一个用户。如果你也想多看几篇文章、在 Windows 上找 RSS 阅读器，不妨试试；用得别扭，就来提 issue。

对我来说，改 DNS 就是其中之一。

切个 114 要打开网络设置，找到适配器属性，找到 IPv4，把数字一个一个敲进去——万一哪天想换 Cloudflare 或者 Google DNS，还得再来一遍。更别提测速选最快的了，那可真是看缘分。

所以我就想，能不能做一个桌面小工具，把这些操作攒到一个界面里，点一下就行？

于是就捣鼓出了 ++DNS Chooser++。

它长什么样

应用打开后分三个区域：

• DNS 测速 → 点一下，内置 12 个常用 DNS 挨个测延迟，按快慢排好，最快的那个标个「最快」。
• DNS 设置 → 6 组预设一键选，或者手动敲 IP，应用就行。想恢复 DHCP 也一个按钮。
• 工具 → 清理 DNS 缓存、用指定 DNS 查域名解析，两个常用的诊断功能。

顶部条实时显示当前在用的 DNS 和权限状态，一目了然。

我比较喜欢的几个点

1. 测速是「真 ping」，不是 ICMP

很多测速工具用的是系统 ping 命令（ICMP），但 DNS 实际跑的是 UDP 53 端口，ICMP 快不代表 UDP 也快。

这个工具的做法是 Rust 后端直接发一个真实的 DNS 查询包到 53 端口，等回复，算延迟——更贴近实际体验。

async fn ping_dns(ip: &str, timeout_ms: u64) -> Result<f64, String> {
    let addr = format!("{}:53", ip);
    let socket = UdpSocket::bind("0.0.0.0:0").await?;
    socket.send_to(&build_dns_query(), &addr).await?;
    let result = timeout(Duration::from_millis(timeout_ms), socket.recv_from(&mut buf)).await;
    // ...
}

代码量不大，但效果实在。

2. 权限处理是个「小坑」

改 DNS 和清缓存都需要管理员权限，这是绕不开的。

Windows 上我试过几种方案，最终还是回到了最稳的做法：检测到非管理员 → 界面提示 → 用户自己右键重新以管理员运行。同时也留了个 PowerShell 提权的路子给需要自动化的人。

macOS 那边则是靠 osascript 弹系统对话框来提权。

这个问题的本质是：桌面应用想改系统设置，就得跨过那道安全门槛。没有完美的方案，只有适合场景的取舍。

3. Tauri 2 比 Electron 轻太多了

之前也用 Electron 写过小工具，打包出来动辄一两百 MB。同样的功能换 Tauri 2，安装包不到 10MB，内存占用也低得多。

前端还是熟悉的 React + TypeScript，后端用 Rust 写系统命令的胶水层，再加上 tokio 做异步——写起来很顺手。

技术栈一览

一些不那么技术的小收获

写这个工具的过程中，最让我感慨的反而不是技术本身，而是：

那些我们觉得「就该这么麻烦」的事情，很多时候只是没人做那个「不麻烦的版本」。

改 DNS 本身不复杂，但每次打开五层菜单去改，加起来的时间成本远大于写一个工具的时间。类似的「微小但高频」的痛点，每个人身边应该都有一堆。

如果你也有类似的感受，不妨也试试写个小工具解决自己的痛点——选 Tauri 这样的框架，门槛真的不高。

使用 & 获取

项目已经开源在 GitHub：

:link: ++github.com/z1HwanG/DNS-Chooser++

目前支持 Windows 和 macOS（Linux 没测，理论上可以但需要适配）。

# 自己构建也很简单
git clone https://github.com/z1HwanG/DNS-Chooser.git
cd DNS-Chooser
npm install
npm run tauri:build

如果你也有类似的“手动改 DNS 党”的经历，或者有什么其他小痛点的想法，欢迎聊聊 :grinning_face_with_closed_eyes:

平时玩游戏，偶尔想叫几个朋友一起看。用大直播平台当然可以，但广告多、延迟不稳定，而且路人也能进来，总觉得不够“私人”。

所以我干脆自己搭了一个小直播间：自己推流，朋友打开网页就能看，旁边还能实时聊天。

这套东西是什么

整个方案由两部分组成：

• 直播流服务：负责接收推流、分发播放地址。我使用的是 SRS，这部分由我自己部署和维护。
• ++LiveChat++：我写的一个网页聊天室，负责直播间的聊天、管理员管理，以及推流鉴权。

简单说就是：

OBS 推流
   │
   ▼
SRS 直播服务（自行部署）
   │
   ▼
朋友浏览器播放画面 + LiveChat 聊天

LiveChat 本身是一个独立的 Node.js 项目，不绑定具体的直播服务，通过接口和 SRS 对接。

为什么这样搭

选择自己搭，主要是为了这几个体验：

• 给朋友看，不公开：推流地址带 token，只有知道地址和 token 的人能推流，陌生人顶不了流。
• 低延迟：支持 WebRTC、FLV、HLS 自适应播放，朋友网络好的时候可以做到接近实时。
• 有聊天：朋友边看边聊，比拉语音群更有“一起看”的感觉。
• 没有广告：自己搭的页面干干净净，没有平台推流、没有贴片广告。
• 管理自由：有人刷屏或乱说话，我可以禁言、删消息，甚至踢出去。

LiveChat 的功能

LiveChat 是我这个直播间里的“聊天 + 管理”部分：

• 实时文字聊天，基于 WebSocket；
• 新朋友进来自动加载最近的历史消息；
• 显示当前在线人数和观看人数；
• 断线自动重连；
• 管理员口令登录后可以：
  • 删除消息；
  • 按分钟禁言；
  • 解除禁言；
  • 踢人下线；
• 每个 IP 3 秒最多发 1 条消息，防止刷屏；
• 提供 SRS on_publish 推流鉴权回调，防止陌生人推流。

技术架构

浏览器
  │
  │  HTTPS / WSS
  ▼
Nginx / Caddy 反向代理
  │
  ▼
LiveChat Web 服务（Node.js + Express + ws）
  │
  ▼
MariaDB / MySQL（历史消息、禁言列表）

• 后端：Node.js + Express + ws；
• 数据库：MariaDB / MySQL；
• 前端：原生 JavaScript，没有重框架；
• 播放器：WebRTC / FLV / HLS 自适应，兼容电脑和手机浏览器。

使用体验

我自己用的时候大概是这样的：

1. 打开 OBS，填好推流地址和 token，开始推流；
2. 把直播间网址发给朋友；
3. 朋友打开网页，自动开始播放，旁边就是聊天区；
4. 我在后台登录管理员，可以随时管理消息。

整个过程没有复杂的客户端，朋友只需要一个浏览器。

部署

LiveChat 面向通用 Linux 环境，使用 Docker 部署：

docker compose up -d --build

然后用 Nginx 或 Caddy 反代到 127.0.0.1:3010。

SSL 证书推荐用 Certbot 自动申请（当然我用的1panel:beaming_face:）：

certbot --nginx -d live.example.com

如果用 Caddy，连证书都不用管：

live.example.com {
    reverse_proxy 127.0.0.1:3010
}

SRS 直播服务由用户自行部署，LiveChat 只负责聊天、管理和推流鉴权对接，两者互相独立。

最后

这个项目不算大，但很实用。它让我拥有了一个只属于自己和朋友的游戏直播间：低延迟、有聊天、无广告、不公开。

如果你也喜欢自己折腾，想搭一个给朋友看的私人直播间，可以参考这个思路。

作者介绍：

卢思浩，百万级畅销书作家。如今已出版《你要去相信，没有到不了的明天》、《愿有人陪你颠沛流离》、《离开前请叫醒我》、《我想和你在一起》等作品。一位细腻的生活家，一枚合格的铲屎官。

微信公众号：卢思浩（KveinLu_）

新浪微博：@卢思浩

这是一个奔波的时代。

我们不停告别，又不听重新出发，有些话还来不及讲，就已经分道扬镳。

心情越来越冷淡，很多话找不到人讲，于是什么都埋在心里。

你有千万句话想说，可点开那个对话框，你根本打不出一个字。

你才明白，原来你从一开始就怕被别人看穿，所以宁可孤独。

所以你宁可每天嘻嘻哈哈，也不要被别人看出你真的难受过。

只有在最深的夜里，你才能够允许自己难过。
 
 
人们说，节哀顺变。

人们说，你还有自己的生活。

我们点头，然后把自己埋在工作里。

然后在某个夜里，想起曾经跟亲人在一起的日子。
 
 
孤独是，某天突然下雨，你走在街上，只有你一个人没有带伞；

加班到深夜的你饥饿难耐，却发现周边所有便利店都关门；

期待很多年的电影今天上映，怎么也找不到人陪你去看；

深夜想要找一个人聊天，翻遍通讯录却找不到人说话。

走过了那么远的路，再也找不到人分享风景。
 
 
我知道的，因为我也经历过。

我知道世事无常，反而想用力珍惜；我看到太多绝望，反而读懂了希望。

我经历过漫长的孤独，反而找到了真正重要的东西。

是那些陪在身边的朋友，是那些你不用说都能懂你的人，是那些你内心的渴望。

是那些藏在你心里某个角落，让你想起来就能嘴角上扬的事情。

我们成长，我们遗忘，我们弄丢回忆，我们无能为力。

可日升日落，潮退潮涨，永远有前路，等待前行的人。

  转自抖音

—— 题记

盛夏，八月，聒噪蝉鸣。

我漫步于静谧的砖瓦小道上，鹅黄色暖阳倾泻在我的肩上，静坐，隔壁琴房悠扬的韵律令人听的出了神。梧桐树于地拔起，阳光静悄悄地穿过细隙落下，我有些迷茫的伸出手，抓住了带有余温的光。

那一刻，阳光是暖的。相隔时间线，着乍起的朝阳带着初生般蓬勃，向上，宁静，有力。

借我瞻前顾后，借我执拗如少年，借我一缕阳光让我清醒。

还忆起，那时的两小无猜，你我规规正正的坐于台阶上，一字一顿，字正腔圆的把诗词吐出，背对了，你给我鼓掌叫好；背错了，你神情严肃，给我分析品读。那是的心是甜蜜的，洋溢在空中的诗香将我带入那新奇而又神秘的别样世界。那个时候啊，阳光穿过梧桐树落在书卷上和你的肩头，我就笑你，笑你被簇拥，笑你是拯救人间的神明。“帘外的雨潺潺，春意阑珊；罗衾不耐五更寒，一晌贪欢。”

你教我识花认木读诗句，欢笑声中，我不再是那个小女孩了，你说，那叫成长。

依稀真切记得，那年元旦晚会，你有模有样的指挥舞台剧，江山在你的指点下激昂，我也装模作样地随着你的手势，你的每句话，笨拙又满怀开心地努力，在顽强中愈渐成长。

春叠的纸飞机被风吹散到梦的田野，它交织着时光的银河，让梦得以在浩瀚的星辰间盛开，零碎的星方坠入人间，那是少年对生活、理想的期许而热爱。

那叫成长。

风对云的朝思暮想是躇躇慌张迷茫无错，是无数次小心翼翼地尝试去靠近云端，与风低喃，与云相拥，与山河相见，与期望重逢。

在春花烂漫之中，与生活的甘甜，与成长的相遇。

周国平先生所言 “世上那些可不做的事是做不完的，永远要去做那些值得做的。” 风华正茂的少年，策马扬鞭，驰聘四海，访遍山河，光耀四方，那是成长。

“我的心里，有一簇迎着烈日而生的花，比一切美酒都要芬芳。” 那些我暗自成长的瞬间，那些阳光洒落台阶的瞬间，那些古诗词句的瞬间。

那些成长的瞬间，我抬头，望见你笑着朝我走来，那一瞬间，我才真切的明白，你是漫长成长路上仅存的美好。

他说：“彼方尚有荣光在。”