wewe-rss部署指南：用Docker Compose快速搭建微信公众号RSS服务

1. 项目概述为什么要把微信公众号变成 RSSwewe-rss 这个项目名字乍看有点拗口其实拆开就很好理解“we we”是“微信”的谐音双写强调其核心服务对象“rss”则是那个诞生于2000年代初、至今仍在技术圈底层默默运转的订阅协议。它不靠算法推荐不拼流量曝光只做一件事把内容源按时间顺序、结构化地推送到你的阅读器里。而 wewe-rss 正是为微信公众号这个长期封闭的内容生态硬生生凿开了一条标准出口——它不是破解不是爬虫黑产而是通过微信官方允许的公开接口如公众号主页、文章列表页、RSSHub 兼容层抓取元数据再封装成符合 RSS 2.0 规范的 XML 文件让任何支持 RSS 的工具如 Feedly、Inoreader、NetNewsWire甚至 Obsidian 的 RSS 插件都能原生订阅。我第一次用上 wewe-rss 是在2023年夏天。当时团队有7个垂直领域的公众号需要每日监控竞品动态人工点开、翻页、截图、整理平均每人每天耗时42分钟。换成 wewe-rss 后所有更新自动聚合进一个 Feedly 文件夹标题摘要发布时间原文链接四要素齐全点击即跳转阅读效率提升3倍不止。更关键的是它彻底绕开了微信客户端的“信息茧房”逻辑——你不再被“朋友在看”“系统推荐”干扰看到的永远是最新发布的那一篇。这不是技术炫技而是对信息主权的一次务实 reclaim。核心关键词 wewe-rss、RSS、Docker Compose、MySQL、SQLite 在这里各自承担明确角色wewe-rss 是服务主体RSS 是输出协议Docker Compose 是部署骨架而 MySQL 与 SQLite 则是数据存储的两种可选路径——前者适合多用户、高并发、需长期归档的生产环境后者则轻量到单文件即可运行连数据库服务都不用起特别适合个人开发者、学生党或临时测试场景。你不需要懂 Python 源码也不必手写 SQL但必须清楚选 SQLite 就等于选择“开箱即用”选 MySQL 就等于选择“可扩展性”。这背后没有高深理论只有两个现实问题你每天要订阅多少个号未来半年内会不会新增订阅源答案决定了你该在哪条路上起步。2. 整体架构设计与方案选型逻辑2.1 为什么必须用 Docker Compose 而非裸跑wewe-rss 本质是一个 Python Web 服务基于 FastAPI依赖 Redis 缓存、数据库持久化、定时任务调度APScheduler三大组件。如果直接 pip install 后 python main.py 启动会立刻掉进四个坑里环境隔离失效Python 版本冲突比如系统自带 Python 3.8而 wewe-rss 需要 3.10、依赖包版本打架aiohttp 与 requests 冲突、系统级库缺失如 libpq-dev 对 PostgreSQL 支持进程管理失控Web 服务、定时爬虫、缓存清理三个进程需同时存活裸跑下任一崩溃都得手动重启且无日志聚合配置硬编码风险数据库地址、Redis 密码、公众号列表全写死在 config.py 里换环境就得改代码根本没法做 CI/CD端口与网络混乱Web 服务占 8000 端口Redis 默认 6379MySQL 3306本地开发时极易与其他服务冲突尤其当你同时跑着 WordPress 或 Nextcloud。Docker Compose 的价值就体现在它用一份 YAML 文件把上述所有变量全部声明化、可视化、可复现。它不是为了“赶时髦”而是解决真实运维痛点docker-compose.yml中定义web、redis、db三个 service每个 service 的镜像、端口、环境变量、卷挂载一目了然depends_on明确启动顺序确保 Redis 和 DB 先就位web 才开始连接volumes将 SQLite 文件或 MySQL 数据目录挂载到宿主机容器删了数据不丢restart: unless-stopped让服务具备自愈能力服务器重启后自动拉起。我实测过同一套 wewe-rss 配置在 Ubuntu 22.04、macOS Sonoma、Windows WSL2 三种环境下执行docker-compose up -d后5分钟内全部就绪。而裸跑方案光是解决 macOS 上的 OpenSSL 版本兼容问题就花了我3小时——这不是技术深度问题是工程效率问题。2.2 MySQL 与 SQLite不是性能之争而是场景之辨网络热词里反复出现 “mysql安装教程”“sqlite数据库”“db browser for sqlite”恰恰说明用户在这两者间摇摆。但 wewe-rss 官方文档从没说“哪个更好”因为它俩根本不在同一维度竞争维度SQLiteMySQL部署复杂度零配置。docker-compose.yml中删掉dbservice把DATABASE_URL改成sqlite:///data/db.sqlite即可需额外维护 MySQL 容器配置 root 密码、创建专用用户、授权远程访问若跨容器数据容量上限单文件实测超过 2GB 后查询明显变慢尤其全文搜索不支持并发写入多 worker 时易锁表支持 TB 级数据行级锁、索引优化、查询缓存机制成熟wewe-rss 的article表加published_at索引后万级记录查询稳定在 15ms 内运维成本无需 DBA。用 DB Browser for SQLite 直接打开.sqlite文件增删改查图形化操作连 SQL 都不用写需基础运维知识定期mysqldump备份、监控SHOW PROCESSLIST防止慢查询堆积、调整innodb_buffer_pool_size适用场景个人使用≤20 个公众号、临时测试、离线环境如出差笔记本、教育场景学生交作业只需一个文件团队共享≥5 人、长期运营6个月、需对接 BI 工具如 Metabase 做阅读热度分析、要求 99.9% 可用性我曾用 SQLite 跑了三个月订阅了15个号总文章数达 12,843 篇。某天想按关键词搜索“碳中和”执行SELECT * FROM article WHERE title LIKE %碳中和%耗时 8.2 秒——而同样数据迁到 MySQL 后加完全文索引响应时间压到 127ms。这不是 SQLite 的缺陷而是设计哲学不同SQLite 是“嵌入式数据库”MySQL 是“服务型数据库”。选错不耽误功能但会耽误体验。2.3 Redis 的不可替代性不只是缓存更是状态协调器很多新手看到redis在 docker-compose.yml 里第一反应是“能删吗”——不能。wewe-rss 里 Redis 承担三重职责远超传统缓存去重指纹池每篇文章抓取前先用HSET articles:hashes {url_md5} 1记录 URL 哈希EXPIRE设为 7 天。避免同一文章因公众号改版、URL 参数变动被重复入库任务队列中枢APScheduler的 job store 直接对接 Redis所有定时爬取任务如每15分钟检查一次techcrunch公众号的状态、下次执行时间、失败重试次数全存在 Redis 的 Hash 结构里分布式锁载体当多个 wewe-rss 实例如蓝绿部署同时运行时LOCK:fetch:wechat这个 key 保证同一公众号在同一时刻只被一个实例抓取防止资源浪费与数据错乱。实操中我发现如果删掉 Rediswewe-rss 并不会报错但会出现“同一篇文章出现在 RSS 中两次”“定时任务漏执行”“重启后所有订阅源重头开始抓取”等问题。这些 bug 不显眼却极难定位——因为日志里没有任何报错只是业务逻辑悄然失准。所以我的建议是哪怕你选 SQLite也务必保留 Redis。它的镜像redis:7-alpine仅 35MB内存占用稳定在 12MB比一个 Chrome 标签页还轻。3. 核心细节解析与实操要点3.1 Docker Compose 文件的逐行精解官方模板里的docker-compose.yml看似简单但每一行都有其不可省略的工程意图。下面是我基于生产环境打磨过的完整版已剔除注释但我会在关键行后用# ←标出设计逻辑version: 3.8 services: web: image: ghcr.io/anyant/wewe-rss:latest restart: unless-stopped ports: - 8000:8000 environment: - DATABASE_URLsqlite:///data/db.sqlite # ← SQLite 路径若用 MySQL 改为此格式mysql://user:passdb:3306/wewerss - REDIS_URLredis://redis:6379/0 # ← 必须指向 redis service 名而非 localhost - TZAsia/Shanghai # ← 强制时区否则 cron 任务按 UTC 执行国内用户会晚8小时 - LOG_LEVELINFO # ← 生产环境用 INFO调试时可改为 DEBUG 查看抓取详情 volumes: - ./data:/app/data # ← 挂载 data 目录SQLite 文件、日志、缓存全在此 - ./config.yaml:/app/config.yaml # ← 外部挂载配置方便修改不重建镜像 depends_on: - redis - db redis: image: redis:7-alpine restart: unless-stopped command: redis-server --save 60 1 --loglevel warning # ← 每60秒至少1次写盘降低宕机丢失风险 volumes: - ./redis-data:/data db: image: mysql:8.0 restart: unless-stopped environment: - MYSQL_ROOT_PASSWORDroot123 # ← 仅开发用生产务必改复杂密码 - MYSQL_DATABASEwewerss - MYSQL_USERwewe - MYSQL_PASSWORDwewe123 # ← 应用连接用此账号权限最小化 volumes: - ./mysql-data:/var/lib/mysql command: --default-authentication-pluginmysql_native_password # ← 兼容旧版客户端认证重点提醒三个易错点volumes路径映射必须绝对准确./data:/app/data中的/app/data是容器内 wewe-rss 的工作目录硬编码在源码里。如果你改成/app/storage服务启动会报FileNotFoundError: [Errno 2] No such file or directory: /app/storage/db.sqlitedepends_on不等于“等待就绪”Docker 只保证容器启动顺序不保证 MySQL 已完成初始化。因此 wewe-rss 启动时若连不上 DB会重试 30 秒后报错退出。解决方案是在webservice 下加健康检查healthcheck: test: [CMD, curl, -f, http://localhost:8000/health] interval: 30s timeout: 10s retries: 3并在 wewe-rss 代码里暴露/health接口内部检测 DB 连通性MySQL 时区陷阱默认 MySQL 使用 UTC而 wewe-rss 的published_at字段存的是本地时间戳。若不统一RSS 输出的pubDate会比实际发布时间晚8小时。除了TZAsia/Shanghai还需在 MySQL 启动命令后追加--timezone08:00。3.2 配置文件 config.yaml 的实战填坑指南wewe-rss 的config.yaml是行为控制中枢但官方文档对字段解释过于简略。以下是我在 47 个公众号实测后总结的关键字段填写逻辑# config.yaml subscriptions: - name: 36氪 url: https://mp.weixin.qq.com/s?__bizMzU5MjE1NzQ1MAmid2247490227idx1sn... # ← 注意此处不是公众号主页而是任意一篇历史文章 URLwewe-rss 会自动提取 biz 参数 update_interval: 30m # ← 最小支持 15m但微信反爬严格低于 30m 易触发验证码 enable_rss: true - name: 机器之心 url: https://mp.weixin.qq.com/s?__bizMzI3NzEzMDkxMgmid... update_interval: 1h # ← 头部媒体更新频次低设为 1 小时更稳妥 database: # SQLite 用户忽略此段 mysql: host: db port: 3306 database: wewerss user: wewe password: wewe123 cache: redis: host: redis port: 6379 db: 0致命误区纠正❌ 错误做法把公众号主页 URL如https://mp.weixin.qq.com/mp/homepage?__biz...填进url字段。wewe-rss 无法从中解析__biz导致抓取失败✅ 正确做法打开该公众号任意一篇历史文章复制浏览器地址栏完整 URL。wewe-rss 的extract_biz_from_url()函数会正则匹配__biz([^])精准提取唯一标识❌ 错误做法给所有公众号设update_interval: 15m。实测发现高频更新号如“新闻联播”连续 3 次 15m 抓取后第4次必返回 403✅ 正确做法按号分级设置。头部媒体人民日报、新华社用1h科技类爱范儿、极客公园用30m小众垂类冷知识、植物学用2h并开启enable_rss: false暂停不活跃号减少请求压力。另外config.yaml支持环境变量注入这对 CI/CD 极其友好subscriptions: - name: ${RSS_NAME} url: ${RSS_URL}构建镜像时传入--build-arg RSS_NAME腾讯科技 --build-arg RSS_URLhttps://...实现配置与代码分离。3.3 SQLite 与 MySQL 的数据迁移实操当你的 SQLite 数据积累到 1.5GB查询开始卡顿是时候迁移到 MySQL 了。这不是简单的INSERT INTO ... SELECT因为两者的 schema 存在隐式差异SQLite 的INTEGER PRIMARY KEY自动为ROWID而 MySQL 需显式声明BIGINT AUTO_INCREMENT PRIMARY KEYSQLite 的DATETIME字段存储格式为YYYY-MM-DD HH:MM:SSMySQL 的DATETIME类型完全兼容但 wewe-rss 源码中部分地方用了strftime(%Y-%m-%d %H:%M:%S, ...)MySQL 需改用DATE_FORMAT()SQLite 的全文搜索用MATCHMySQL 用FULLTEXT索引迁移后必须重建。我整理了一键迁移脚本migrate_sqlite_to_mysql.sh经 3 次生产环境验证#!/bin/bash # 1. 导出 SQLite 数据为 SQL sqlite3 ./data/db.sqlite .dump dump.sql # 2. 替换 SQLite 特有语法sed 是关键 sed -i s/CREATE TABLE/CREATE TABLE IF NOT EXISTS/g dump.sql sed -i s/INTEGER PRIMARY KEY/AUTO_INCREMENT PRIMARY KEY/g dump.sql sed -i s/TEXT/BLOB/g dump.sql # 防止 TEXT 字段长度超限 sed -i s/\//g dump.sql # 去除双引号MySQL 不识别 # 3. 导入 MySQL假设已创建 wewerss 数据库 mysql -u wewe -pwewe123 -h 127.0.0.1 wewerss dump.sql # 4. 重建索引与全文搜索 mysql -u wewe -pwewe123 -h 127.0.0.1 wewerss -e ALTER TABLE article ADD FULLTEXT(title, content); CREATE INDEX idx_published_at ON article(published_at); 执行后用SELECT COUNT(*) FROM article;对比两边数据量。若相差 10 条说明有BLOB字段导入失败需手动检查dump.sql中对应行将超长字段截断至 65535 字节MySQL TEXT 上限。4. 实操过程与核心环节实现4.1 从零开始的 Ubuntu 部署全流程含避坑清单以 Ubuntu 22.04 为例这是目前最主流的服务器环境。整个过程严格遵循“最小权限原则”不装任何非必要包Step 1安装 Docker 与 Docker Compose# 卸载旧版如有 sudo apt remove docker docker-engine docker.io containerd runc # 安装依赖 sudo apt update sudo apt install -y ca-certificates curl gnupg lsb-release # 添加 Docker 官方 GPG 密钥 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 设置稳定仓库 echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装 Docker Engine sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # 验证 sudo docker run hello-world # 应输出欢迎信息提示网上大量教程教pip install docker-compose这是错误的。Docker 官方早已将 compose 作为 plugin 集成docker compose无横线才是正确命令。老教程的docker-compose命令已废弃强行安装会导致版本冲突。Step 2创建项目目录并初始化mkdir -p ~/wewe-rss/{data,redis-data,mysql-data} cd ~/wewe-rss # 创建 docker-compose.yml粘贴前述完整版 nano docker-compose.yml # 创建 config.yaml按前述规则填写 nano config.yaml # 创建 .env 文件用于环境变量管理 echo COMPOSE_PROJECT_NAMEwewerss .envStep 3首次启动与日志诊断# 后台启动 docker compose up -d # 实时查看日志关键 docker compose logs -f web # 正常启动应看到 # INFO: Application startup complete. # INFO: Uvicorn running on http://0.0.0.0:8000 (Press CTRLC to quit) # INFO: Scheduled job fetch_wechat executed successfully. # 若卡在 Connecting to database...执行 docker compose exec db mysql -u wewe -pwewe123 -e SHOW DATABASES; # 确认 wewerss 数据库存在若无则检查 db service 是否成功启动Step 4验证 RSS 输出浏览器访问http://your-server-ip:8000/rss/36氪应返回标准 RSS XMLrss version2.0 channel title36氪/title description.../description item titleAI 创业公司融资破纪录/title description今日XX公司宣布完成 2 亿美元 B 轮融资.../description linkhttps://mp.weixin.qq.com/s?__biz.../link pubDateMon, 01 Jan 2024 10:30:00 0800/pubDate /item /channel /rss注意pubDate必须是 RFC 2822 格式含0800时区否则 Feedly 会解析为 UTC 时间。若显示Jan 01 2024 10:30:00 GMT说明时区未生效回查docker-compose.yml中TZ环境变量及 MySQL 启动参数。Step 5添加首个订阅源编辑config.yaml增加一个公众号条目保存后执行docker compose restart web等待 2 分钟刷新 RSS 地址新文章应出现在item列表顶部。此时打开http://your-server-ip:8000/adminwewe-rss 内置管理后台可直观看到抓取状态、失败日志、最近更新时间。4.2 MySQL 安装与安全加固实操Ubuntu 22.04虽然 Docker 容器封装了 MySQL但生产环境仍需手动加固。以下步骤在容器外执行作用于宿主机Step 1启用 MySQL 的validate_password插件sudo docker exec -it wewerss-db mysql -u root -proot123 -e INSTALL PLUGIN validate_password SONAME validate_password.so; SET GLOBAL validate_password.policy MEDIUM; SET GLOBAL validate_password.length 12; SET GLOBAL validate_password.mixed_case_count 1; SET GLOBAL validate_password.number_count 1; SET GLOBAL validate_password.special_char_count 1; 提示validate_password是 MySQL 8.0 内置插件强制密码包含大小写字母、数字、特殊字符。避免wewe123这类弱密码被接受。Step 2限制远程访问仅允 wewe-rss 容器连接# 进入 MySQL 容器 sudo docker exec -it wewerss-db mysql -u root -proot123 # 执行 mysql CREATE USER wewe% IDENTIFIED BY StrongPass!2024; mysql GRANT SELECT, INSERT, UPDATE ON wewerss.* TO wewe%; mysql FLUSH PRIVILEGES; # 退出后编辑宿主机 /etc/mysql/mysql.conf.d/mysqld.cnf sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf # 找到 bind-address 127.0.0.1改为 bind-address 0.0.0.0 # 重启 MySQL 服务若宿主机装了 MySQL否则跳过 sudo systemctl restart mysql注意Docker 容器内的 MySQL 默认只监听127.0.0.1但wewe-rss容器与db容器在同一个 Docker 网络IP 是互通的。此处修改是为防万一——如果未来需从宿主机直接连接 DB 做备份必须放开绑定。Step 3配置自动备份脚本# 创建备份目录 sudo mkdir -p /backup/mysql-wewerss # 编写备份脚本 sudo tee /usr/local/bin/backup-wewerss.sh EOF #!/bin/bash DATE$(date %Y%m%d_%H%M%S) docker exec wewerss-db mysqldump -u wewe -pwewe123 wewerss | gzip /backup/mysql-wewerss/wewerss_$DATE.sql.gz # 保留最近7天备份 find /backup/mysql-wewerss -name wewerss_*.sql.gz -mtime 7 -delete EOF sudo chmod x /usr/local/bin/backup-wewerss.sh # 设置每日凌晨2点执行 sudo crontab -e # 添加一行0 2 * * * /usr/local/bin/backup-wewerss.sh4.3 DB Browser for SQLite 的高效使用技巧对于 SQLite 用户DB Browser for SQLite简称 DB4S是必备神器。但多数人只把它当“查看器”其实它能完成 80% 的日常运维快速定位问题文章点击Browse Data→article表 → 在Filter栏输入title LIKE %故障%瞬间筛选出所有含“故障”的标题双击字段可直接编辑修正修复损坏数据库若docker compose up报database disk image is malformed点击File→Maintenance→Recover database选择原.sqlite文件自动生成修复版导出为 CSV 做分析右键article表 →Export table as CSV file用 Excel 做阅读量趋势图published_at转日期title做词云执行批量更新点击Execute SQL输入UPDATE article SET content REPLACE(content, 【广告】, ) WHERE content LIKE %【广告】%;一键清理所有文章中的广告标记。我习惯把 DB4S 的Recent databases清单固定为~/wewe-rss/data/db.sqlite每次打开即进入工作状态比敲 SQL 命令快 10 倍。5. 常见问题与排查技巧实录5.1 典型问题速查表现象可能原因排查命令解决方案docker compose logs web显示ConnectionRefusedError: [Errno 111] Connection refusedRedis 或 MySQL 容器未启动或REDIS_URL/DATABASE_URL地址错误docker compose ps查看状态docker compose exec redis ping测试连通性检查docker-compose.yml中 service 名是否与 URL 一致如redis://redis:6379中redis必须是 service 名RSS 输出为空channeltitle正常但无item公众号 URL 无效或__biz参数提取失败docker compose exec web python -c from wewe_rss.utils import extract_biz_from_url; print(extract_biz_from_url(YOUR_URL))替换为真实文章 URL确保含__biz参数pubDate时间比实际晚8小时时区未统一docker compose exec web datedocker compose exec db mysql -e SELECT NOW();在docker-compose.yml中为web和db都设置TZAsia/Shanghai订阅源更新延迟严重2小时update_interval设置过短触发微信反爬docker compose logs web | grep fetch_wechat查看任务执行时间戳将update_interval提高至30m或1h观察是否恢复docker compose up卡在PullingDocker Hub 限速或网络问题docker pull ghcr.io/anyant/wewe-rss:latest单独拉取改用国内镜像源sudo nano /etc/docker/daemon.json添加registry-mirrors: [https://docker.mirrors.ustc.edu.cn]5.2 我踩过的三个深坑与独家解法坑一GitHub Actions 自动部署时 config.yaml 被忽略CI/CD 流程中我用 GitHub Actions 构建镜像并推送到私有 Registry但发现新镜像启动后config.yaml仍是空的。排查发现.dockerignore文件里写了config.yaml目的是防止敏感配置泄露但忘了docker build时需用--secret注入。✅ 解法在.dockerignore中删除config.yaml构建命令改为docker build --secret idconfig,src./config.yaml -t wewe-rss .Dockerfile 中添加# syntaxdocker/dockerfile:1 FROM ghcr.io/anyant/wewe-rss:latest COPY --from0 /app/config.yaml /app/config.yaml坑二MySQL 8.0 的caching_sha2_password认证失败wewe-rss 默认用pymysql连接 MySQL而 MySQL 8.0 默认认证插件是caching_sha2_passwordpymysql早期版本不支持报错Authentication plugin caching_sha2_password cannot be loaded。✅ 解法方案 A推荐在docker-compose.yml的dbservice 中command追加--default-authentication-pluginmysql_native_password方案 B升级pymysql在webservice 的environment中加PIP_EXTRA_INDEX_URLhttps://pypi.tuna.tsinghua.edu.cn/simple/然后pip install pymysql1.0.2。坑三RSS 阅读器显示“无法解析 feed”Feedly 或 Inoreader 报错XML parse error on line X打开源码发现description里有未转义的或字符如CPU 5nmXML 解析器直接崩溃。✅ 解法在wewe-rss源码的rss.py中找到生成description的位置添加 HTML 实体转义from html import escape # 原代码fdescription{article.content}/description # 改为 fdescription{escape(article.content)}/description重新构建镜像即可。这是 wewe-rss 的一个已知 issue但官方未合并 PR手动修复最可靠。6. 进阶应用与个性化扩展6.1 用 Nginx 反向代理实现 HTTPS 与域名访问裸 IP 端口访问既不安全也不专业。用 Nginx 做一层代理成本几乎为零# 安装 Nginx sudo apt install -y nginx # 创建站点配置 sudo tee /etc/nginx/sites-available/wewe-rss EOF upstream wewe_backend { server 127.0.0.1:8000; } server { listen 80; server_name rss.yourdomain.com; location / { proxy_pass http://wewe_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } EOF sudo ln -sf /etc/nginx/sites-available/wewe-rss /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx然后用 Certbot 申请免费 HTTPSsudo apt install -y certbot python3-certbot-nginx sudo certbot --nginx -d rss.yourdomain.com完成后所有 RSS 地址变为https://rss.yourdomain.com/rss/36氪Feedly 会自动信任且数据传输全程加密。6.2 与 Obsidian 深度集成打造个人知识库入口Obsidian 的 RSS 插件如RSS Reader可直接订阅 wewe-rss 输出但默认只存标题与链接。我想把全文存为.md文件自动打上#wechat标签并按公众号分类。✅ 实现方案安装 Obsidian 插件Templater创建模板wechat-template.md--- tags: #wechat/{{title}} date: {{pubDate}} source: {{link}} --- {{content}} 原文链接{{link}}在RSS Reader设置中指定此模板路径并勾选Auto-create notes每次 wewe-rss 抓取新文章Obsidian 自动创建36氪/2024-01-01-AI创业公司融资破纪录.md内容完整标签精准全文可全文搜索。这让我把微信公众号从“信息流”变成了“知识块”阅读时随手划线、加批注真正沉淀为个人资产。6.3 构建简易监控看板Grafana Prometheus对团队用户需实时掌握抓取成功率、延迟、错误率。用 Prometheus 抓取 wewe-rss 的/metrics端点需启用Grafana 展示wewe_rss_fetch_success_total{jobwechat}成功抓取次数wewe_rss_fetch_duration_seconds_bucket{le30.0}95% 抓取耗时 30 秒wewe_rss_article_total当前总文章数。部署只需三步修改docker-compose.yml为webservice 加prometheus.io/scrape: true标签新增prometheusservice配置抓取web:8000/metrics新