MacOS

开场：告别内网穿透的“开盲盒”体验 在多设备办公和 HomeLab 运维中，远程访问内网资源一直是个痛点： frp / 端口映射：家宽没有公网 IP，或者公网 IP 隔三差五变动，还要针对每个端口配置穿透规则。 ZeroTier / Tailscale：虽然方便，但依赖第三方中央控制平面，国内网络偶发打洞失败或握手延迟飙升。 传统 OpenVPN / IPsec：配置繁琐、代码庞大，在笔记本睡眠唤醒或 Wi-Fi 切换后重连极慢。 WireGuard 的出现彻底解决了这些问题： 代码精简：仅约 4,000 行核心代码，直接集成进 Linux 内核，吞吐量接近线速。 现代密码学：基于 Noise 协议框架与 Curve25519、ChaCha20-Poly1305，没有臃肿的握手协商。 极简身份机制：每个节点一对公私钥，无状态（Stateless）UDP 通信，原生支持移动漫游（Roaming）。 本文将从零开始，手把手记录一套完整的 Ubuntu 云端中继 + 家庭设备 + macOS 终端极客接入 的生产级配置方案，并深度复盘在 macOS 上实现系统级 LaunchDaemon 开机常驻与事件驱动自愈重连的实战经验。 1. 架构设计与网络规划 WireGuard 在协议层没有严格的“客户端”与“服务端”之分，所有节点都是平等的 Peer。但在实际拓扑中，我们通常将拥有固定公网 IP 的云服务器作为汇聚与中继节点。 拓扑规划 ┌───────────────────────────────┐ │ Ubuntu 云服务器 (Node A) │ │ 公网 IP: 198.51.100.1 │ │ 虚拟 IP: 10.100.0.1/24 │ └──────────────┬────────────────┘ │ WireGuard UDP :51820 ┌────────────┴────────────┐ │ │ ┌────────┴────────┐ ┌────────┴────────┐ │ 家庭 NAS / PC │ │ MacBook 笔记本 │ │ (Node B) │ │ (Node C) │ │ 虚拟 IP: │ │ 虚拟 IP: │ │ 10.100.0.2/24 │ │ 10.100.0.3/24 │ └─────────────────┘ └─────────────────┘ 节点分配表 节点 角色 真实网络 虚拟 IP (wg0) 监听端口 / 对端 Node A 云端中继网关 拥有固定公网 IP 10.100.0.1/24 监听 51820 (UDP) Node B 家庭服务器（Ubuntu 24 Server） 家庭宽带内网 (NAT) 10.100.0.2/24 对端指向 Node A Node C macOS 办公本 移动办公 / Wi-Fi (NAT) 10.100.0.3/24 对端指向 Node A 网段选择提示：虚拟子网建议使用 10.100.0.0/24 等不常用网段，避免与家庭路由器默认的 192.168.1.0/24 发生网段冲突。 ...

摘要：GitHub 上的 jaywcjlove/awesome-mac 是最大的 macOS 软件清单之一，但 1000+ 条目堆在一个 Markdown 里，找东西全靠肉眼滚。我做了一个单页检索版：把整份清单解析成结构化数据，支持即时搜索、分类筛选、标签过滤，收录 1110 款软件、24 个分类，并且每周自动跟随上游更新。在线地址：fxio.site/p/awesome-mac.html 为什么不直接看 GitHub 仓库？ awesome-mac 仓库很好，但它本质上是一份超长 Markdown： 1100+ 款软件按目录顺序排列，找一个「录屏工具」要滚很久 没有搜索框，浏览器 Ctrl+F 只能匹配文字，匹配不到分类语义 无法按「免费 / 开源 / App Store」快速过滤 检索页把 README 解析成 JSON，前端纯静态渲染，解决了这三个问题。 功能一览 功能 说明 🔍 即时搜索 按名称、描述、分类模糊匹配，命中关键词高亮 📂 分类筛选 24 个分类：开发者工具、设计和产品、AI 工具、音视频、阅读写作等 🏷️ 标签过滤 开源 / 免费 / App Store / 原生，一键筛选 📦 GitHub 直达 开源项目卡片直接带 GitHub 链接 🔗 点击即开 点卡片直接打开软件官网 整页是单个 HTML 文件（约 334KB），数据全部内嵌，无后端依赖，离线也能用。 数据规模（2026-08-05） 1110 款软件，24 个分类 前三大类：其它实用工具 307、开发者工具 202、设计和产品 126 AI 工具分类已有 39 款，是最近增长最快的分类 自动更新 本地配了一个每周定时任务：拉取 awesome-mac 最新代码 → 重新解析生成页面 → 上传到预览服务器。上游新增软件一周内自动收录。 ...

摘要：还在手动暂停视频截字幕？还在边看直播边手打笔记？本文介绍的 screen_ocr.py 脚本，利用 macOS 原生 screencapture 与 Vision API，结合 Python 的 imagehash 库，实现了一个“框选即监控、变化即记录”的实时 OCR 笔记神器。特别适合视频字幕提取、在线会议记录及动态网页监控。 1. 工具简介：你的屏幕“速记员” 在日常开发与学习中，我们经常面临以下场景： 看网课/直播：老师讲得太快，来不及记笔记。 提取视频字幕：视频没有提供字幕文件，只能盯着画面看。 监控动态界面：某个网页或软件界面不断刷新数据，需要手动记录。 screen_ocr.py 专为解决这些痛点而生。它运行后，你只需在屏幕上框选出感兴趣的文字区域，它就会在后台“盯着”这块区域。一旦检测到画面内容变化（如字幕变了、数据刷新了），它会立即调用 macOS 原生的 OCR 引擎识别文字，并按时间顺序写入 Markdown 文件。 2. 核心功能解析 2.1 原生框选：screencapture -i 传统 Python 截图工具（如 pyautogui）通常无法精确框选区域，或者依赖庞大的 GUI 库（如 tkinter、PyQt）。screen_ocr.py 直接调用了 macOS 内置的 screencapture -i 命令。 体验：按下运行键，鼠标变成十字准星，跟平时用 Cmd+Shift+4 一模一样。 优势：零依赖、原生体验、支持 Retina 屏幕高清截图。 2.2 智能去抖：感知哈希 (pHash) 比对 如果每秒钟都调用 OCR，不仅浪费资源，还会产生大量重复文本（比如画面没变，但识别结果可能因为噪点略有不同）。 脚本引入了 imagehash 库，计算图片的 pHash (感知哈希)。 原理：将图片缩放、灰度化、DCT 变换后生成一个 64 位的指纹。 判定：只有当新旧两帧图片的汉明距离（Hamming Distance）大于 5 时，才认为画面发生了实质变化。 效果：完美过滤静止画面，仅在文字更新时触发识别。 2.3 极速识别：macOS Native Vision API 通过 ocrmac 库封装，直接调用 macOS 系统级的 VNRecognizeTextRequest。 ...

摘要：在处理视频关键帧文本/字幕提取时，我们常常面临“多帧重复”与“识别效率低”两大痛点。本文记录了从传统 PaddleOCR 方案切到 macOS Native Vision API 的全过程，并通过 Python 实现了内存级模糊去重与灵活的批量导出。在 M4 Pro 芯片加持下，识别速度直升至每秒 10+ 张！ 1. 背景与痛点 在视频内容分析、字幕提取或文档视频化等场景中，我们通常需要将视频按帧导出为图片并识别其中的文本。然而，这一过程有两个核心痛点： 画面重复率极高：相邻的关键帧往往包含完全相同或极其相似的文本，直接输出会导致结果大量冗余。 传统 OCR 引擎偏重：像 PaddleOCR 这类业界顶级的开源方案，在 NVIDIA 显卡或 x86 CPU 上表现优异，但在 Apple Silicon（如 M4 Pro）上运行时，由于需要经过 Python 运行时与跨平台计算图调度，单图识别耗时较长（100~300ms/帧），处理大批量图片时风扇直吹、资源占用较高。 2. 方案对比：PaddleOCR vs macOS Native Vision 为了在 Mac 上获得最佳效率，我们对比了两种技术路线： 维度 PaddleOCR (Python) macOS Native Vision API (ocrmac) 底层硬件支持 主走 CPU 多线程推理 / MPS 支持有限 深度适配 Apple Neural Engine (NPU) + Metal 单图识别速度 ~100 - 300 ms / 帧 ~50 - 100 ms / 帧（每秒 10+ 张） 资源与内存占用 需加载完整神经网络权重与 Python 运行库 直接调系统驻留服务，占用微乎其微 初始化开销 首次运行需下载 100MB+ 模型模型并做连通性检测 零下载、零模型开销，开箱即用 最佳适用场景 复杂工业票据、表格结构化解析、跨平台部署 macOS 平台下的视频关键帧、截图、常规文本快速提取 结论：在 macOS 环境下处理视频字幕与常规截图，原生 Vision API 凭借对 NPU 的极致调度，性能堪称“降维打击”。 ...