手写系列从零到一：Github开源你的第一个项目
下面以我开源yiQGuard为例，给大家分享一下从0到1开源自己项目的全流程，我的流程和规范不能保证全对，不同开源项目也有不同的规范，大家参考即可。
⭐️项目地址：https://github.com/ziyifast/yiq-guard
第 01 节：想法与规划
1. 好项目的三个标准
- 解决真实痛点 --- 你自己或身边人真的需要它
- 足够聚焦 --- 一句话能说清楚它做什么
- 有完成边界 --- 知道做到什么程度算"能用了"
💡 很多人想做"一个平台"------太大了。先做一个"一键解决一个小问题"的工具。
2. 快速验证技术可行性
在写代码前，花 10 分钟确认核心技术是否可行。避免做到一半发现系统限制/权限要求等"不可能完成"的功能。
最小闭环的标准：能从头到尾跑通一个完整流程。
对 yiq-guard 来说：启动 → 拦截 Cmd+Q → 弹出提示 → 用户选择 → 应用退出/保持 = 闭环完成。 此时的代码可以丑、可以慢、可以缺功能------但核心路径必须通。
示例（yiq-guard）：
- 目标：拦截全局 Cmd+Q
- 快速验证：查阅 macOS 文档 → 需要 辅助功能权限 + CGEventTap 接口
- 结论：可行，但需处理权限申请逻辑
👉 建议：写下自己项目依赖的关键技术点，用 AI辅助配合一些 Google / 官方文档快速确认是否存在障碍。
3. yiq-guard 的例子
bash
痛点：macOS 上 Cmd+Q 和 Cmd+W 太近，经常误触退出
方案：拦截 Cmd+Q，要求二次确认才退出
边界：能拦截 → 能配置模式 → 能打包成 .app → 发布想法来源：自己用电脑时真实遇到的问题。不是凭空想的。我自己就经常误触command+Q，导致有些程序因为误触退出，有些文件又没保存就直接退出了。大家可以想想自己日常中有哪些痛点，开源社区中又没有自己满意的解决方案的。
⭐️灵感推荐：下面是一些个人独立产品发布的平台，大家可以看看比较受欢迎的是哪些产品，以及他们的出发点、发现的痛点是哪些、实现方式是怎样的。
- 产品派 --- 中文独立产品社区，适合了解国内开发者在做什么
- Product Hunt --- 全球最大产品发布平台，看国际趋势
- Indie Hackers --- 独立开发者社区，侧重商业模式和变现
- GitHub Trending --- 技术向，看最近什么技术栈/工具在火
- GitHub Awesome 列表 --- 按主题分类的优质项目集合
4. 写一个一句话描述
这句话会成为你 GitHub 仓库的描述、README 第一行、文章标题：
bash
yiq-guard --- macOS 防误触工具，拦截 Command+Q，避免意外关闭应用程序。模板：[项目名] --- [做什么]，[解决什么问题]。
如果你写不出来------说明项目还没想清楚，先想清楚再写代码。
5. 项目结构规划
先画骨架，再填肉
不要急着写代码。先把目录结构定好：
Windows 用户提示：原生命令提示符不支持 mkdir -p 和 touch。建议使用 Git Bash、WSL，或者手动创建文件夹和空文件。
bash
mkdir yiq-guard && cd yiq-guard
# 核心代码
mkdir -p yiq-guard/modes yiq-guard/ui
# 测试
mkdir -p tests/mocks
# 创建空文件占位
touch main.py setup.py requirements.txt
touch yiq-guard/__init__.py
touch README.md LICENSE .gitignore通用项目结构
bash
your-project/
├── README.md # 项目说明（最重要！）
├── LICENSE # 开源协议
├── .gitignore # Git 忽略规则
├── requirements.txt # 依赖（Python）/ package.json（Node.js）
├── build.sh # 一键构建脚本
├── src/ 或 your_package/ # 源代码
├── tests/ # 测试
└── CONTRIBUTING.md # 贡献指南命名规范
仅供参考，不同项目、不同语言有不同的规范。
| 项目 | 规范 | 示例 |
|---|---|---|
| 仓库名 | 推荐全小写+连字符 | yiq-guard |
| Python 包名 | 小写+下划线 | yiqguard |
| 类名 | PascalCase | EventTap |
| 函数/变量 | snake_case | handle_cmd_q |
| 常量 | 全大写+下划线 | DOUBLE_PRESS_INTERVAL |
本节小结
- 我的项目能解决一个真实痛点
- 我能用一句话说清楚它做什么
- 我知道做到什么程度算"可以发布"
- 我已经画好了目录结构骨架
第 02 节：编码实战
这一部分现在有了AI工具，门槛大大降低，鼓励大家多去尝试，发散自己的思维。
1. 核心原则
- 先跑通最小闭环 --- 能证明方案可行就够了
- 模块化 --- 每个文件只做一件事
- 写注释 --- 特别是"为什么"，而不是"是什么"
2. 开发顺序：先验证，后完善
不要从 UI 开始写。先验证核心技术是否可行。
yiq-guard 的开发顺序
bash
1. event_tap.py --- 先验证能不能拦截 Cmd+Q（技术可行性）
2. config.py --- 配置读写（最简单的模块，建立信心）
3. confirm_mode.py --- 第一个保护模式（最小可用产品）
4. menu_bar.py --- 用户界面（能看到效果了！）
5. app_delegate.py --- 组装所有模块
6. main.py --- 入口，完成闭环为什么这个顺序
- 第 1 步就验证最大风险：如果拦截 Cmd+Q 做不到，后面全白做
- 从最简单到最复杂：config.py 几十行就写完，给自己正反馈
- UI 放后面：UI 是锦上添花，核心逻辑才是骨架
3. 模块化设计
每个文件职责单一：
bash
yiq-guard/
├── event_tap.py --- 只做键盘事件拦截
├── config.py --- 只做配置读写
├── permissions.py --- 只做权限检查
├── modes/
│ ├── confirm_mode.py --- 只做弹窗确认逻辑
│ └── double_press_mode.py --- 只做双击检测逻辑
└── ui/
├── menu_bar.py --- 只做菜单栏渲染
├── settings_window.py --- 只做设置面板
└── toast.py --- 只做 Toast 显示好处：
- 改一个模块不影响其他模块
- 测试可以单独测每个模块
- 新人看代码时一目了然
4. 注释规范
bash
# ✅ 好：说明"为什么"
# Tap 被系统超时禁用 → 立即重新启用，避免用户键盘卡死
if event_type == _TAP_DISABLED_BY_TIMEOUT:
CGEventTapEnable(tap, True)
# ❌ 差：说明"是什么"（代码本身已经表达了）
# 如果事件类型是超时，启用 tap
if event_type == _TAP_DISABLED_BY_TIMEOUT:
CGEventTapEnable(tap, True)什么时候需要注释：
| 场景 | 需要注释 |
|---|---|
| 代码做了违反直觉的事 | ✅ "为什么这样做" |
| 使用了 magic number | ✅ "这个数字代表什么" |
| 有已知的限制/坑 | ✅ "这里有个坑，原因是..." |
| 代码逻辑很直观 | ❌ 不需要 |
| 函数名已经表达意图 | ❌ 不需要 |
5. 错误处理
原则：工具类应用永远不要 crash。用默认值兜底。
python
# ✅ 好：优雅降级，不崩溃
def load():
try:
with open(CONFIG_FILE, "r") as f:
return json.load(f)
except (json.JSONDecodeError, OSError):
return dict(DEFAULTS) # 配置损坏时用默认值
# ❌ 差：直接崩溃，用户体验极差
def load():
with open(CONFIG_FILE, "r") as f:
return json.load(f) # 文件不存在就 crash本节小结
- 我先验证了核心技术可行性
- 每个文件只负责一件事
- 注释说的是"为什么"而不是"是什么"
- 错误处理用优雅降级而不是 crash
第 03 节：测试与质量
1. 为什么开源项目必须有测试？
- 证明可靠 --- 别人看到 "46 passed" 才敢用
- 保护重构 --- 改代码后跑一遍测试，知道没改坏
- 方便贡献 --- 别人提 PR 时，CI 自动验证
没有测试的开源项目 = 没有安全网的走钢丝。
2. 测试金字塔
bash
╱ 端到端测试 ╲ ← 少量，真机运行
╱ 集成测试 ╲ ← 适量，模块协作
╱ 单元测试 ╲ ← 大量，每个函数对于工具类项目，单元测试 + Mock 就足够了。
3. 写第一个测试
python
# tests/test_double_press_mode.py
def test_single_press_does_not_quit():
"""单次按 Cmd+Q 不应该退出应用"""
mode = DoublePressMode()
quit_called = False
def on_quit(app):
nonlocal quit_called
quit_called = True
mode.handle(on_quit=on_quit)
assert quit_called is False # 只按了一次，不应退出测试命名规范：test_行为_条件_期望结果
4. Mock 技巧：跨平台测试
macOS 的 Cocoa/Quartz API 在 Linux 上不存在。怎么办？Mock 掉：
python
# tests/mocks/macos_mocks.py
import sys
from unittest.mock import MagicMock
# 告诉 Python："Cocoa 模块？有的有的！（假的）"
sys.modules['Cocoa'] = MagicMock()
sys.modules['Quartz'] = MagicMock()
sys.modules['AppKit'] = MagicMock()然后在测试文件开头：
python
from tests.mocks.macos_mocks import install_mocks
install_mocks() # 必须在 import 项目代码之前！
# 现在可以安全 import 了
from yiq-guard.modes.double_press_mode import DoublePressMode效果：46 个测试可以在 Linux/CI 上跑，不需要 macOS。
5. 运行测试
python
pip install pytest
python -m pytest tests/ -v
# 输出：
# tests/test_config.py::test_load_returns_defaults ... PASSED
# tests/test_double_press_mode.py::test_single_press ... PASSED
# ...
# ====== 46 passed in 0.13s ======6. 测试覆盖了什么
| 模块 | 测试内容 |
|---|---|
| config.py | 加载/保存/损坏恢复/目录创建 |
| confirm_mode.py | 确认退出/取消/显示应用名 |
| double_press_mode.py | 单击无效/双击退出/超时重置 |
| event_tap.py | 初始化/队列/快捷键配置/常量 |
| permissions.py | 有权限/无权限 |
| settings_window.py | 面板交互/回调 |
7. 什么时候该加测试
- ✅ 每加一个新功能
- ✅ 每修一个 Bug（先写能复现 bug 的测试，再修）
- ✅ 重构前（确保改完行为不变）
本节小结
- 项目有单元测试
- 测试可以跨平台运行（Mock 外部依赖）
- python -m pytest tests/ -v 全部通过
- 每个核心模块都有对应测试
第 04 节：开源必备文件
1. 必备文件清单
| 文件 | 重要性 | 作用 |
|---|---|---|
| README.md | ⭐⭐⭐⭐⭐ | 项目门面，决定别人是否用你的项目 |
| LICENSE | ⭐⭐⭐⭐⭐ | 法律保护，没有它别人不敢用 |
| .gitignore | ⭐⭐⭐⭐ | 防止提交垃圾文件 |
| requirements.txt | ⭐⭐⭐⭐ | 让别人能复现你的环境 |
| build.sh | ⭐⭐⭐⭐ | 一键安装/打包，降低门槛 |
| uninstall.sh | ⭐⭐⭐ | 体面退出，给用户安全感 |
| CONTRIBUTING.md | ⭐⭐⭐ | 指导别人如何贡献 |
2. README 黄金结构
写 README 的顺序建议：先写"快速开始"（因为这是你最清楚的），再补"功能特性"，最后写"开发指南"。不要试图一次写完，先发布 60 分的 README，后续迭代完善。
bash
1. 标题与简介 (Header & Tagline)
项目名称：清晰醒目。
一句话描述：使用引用块 (>) 突出显示。目的是让访客在 3秒内 明白这个项目是做什么的，解决了什么痛点。
2. 徽章栏 (Badges)
居中展示：使用 HTML <div align="center"> 让徽章居中，视觉上更专业。
关键信息：包含版本号、支持平台、许可证以及构建状态（CI/CD）。这些徽章能迅速建立用户对项目健康度和维护状态的信任。
3. 🚀 快速开始 (Quick Start)
目标用户：普通终端用户。
安装方式：优先推荐"一键安装脚本"，因为这是最便捷的方式；同时提供手动下载链接作为备选。
基本用法：提供最常用的命令示例（如 --help 或启动命令），让用户无需阅读长篇文档即可运行项目。
4. ✨ 功能特性 (Features)
列表展示：使用 bullet points 列出核心功能。
简明扼要：每个功能点用简短的语言描述，避免冗长，方便用户快速扫描项目能力。
5. ⚙️ 配置说明 (Configuration)
文件位置：明确告知配置文件的路径。
代码高亮：使用 ````toml` 代码块展示示例配置，并添加注释解释关键参数。这比纯文字描述更直观，方便用户复制修改。
6. 🛠️ 开发指南 (Development)
目标用户：开发者及贡献者。
源码构建：提供从 git clone 到 make build 的完整步骤，确保开发者能在本地跑通项目。
项目架构：使用树状结构 (tree) 展示目录结构，帮助新人快速理解代码组织逻辑（如核心逻辑、CLI入口、工具函数分离）。
贡献规范：`在这里插入代码片`
代码风格：指明遵循的标准（如 PEP 8）。
提交信息：推荐约定式提交（Conventional Commits），便于自动化生成 changelog。
测试与流程：明确测试命令和 PR 流程，降低贡献门槛。
7. ❓ 常见问题 (FAQ)
预判问题：列出用户最容易遇到的坑（如配置重置、平台兼容性）。
问答格式：加粗问题，简洁回答，减少维护者的重复答疑工作。
8. 📄 许可证 (License)
法律声明：明确开源协议（如 MIT），并链接到具体的 LICENSE 文件，保护作者权益并告知用户使用权限。3. 脚本化 = 丝滑体验
黄金法则：用户 clone 后，一条命令就能跑起来。
bash
# ✅ 好的体验
git clone ... && cd yiq-guard && bash build.sh --run
# ❌ 糟糕的体验
git clone ...
cd project
python3 -m venv venv
source venv/bin/activate
pip install --upgrade pip
pip install -r requirements.txt
pip install py2app
python setup.py py2app
open dist/xxx.app把一大堆命令封装进build.sh，用户只需一条命令。卸载同理：一个 uninstall.sh 让人觉得你的项目很专业。
4. 依赖管理最佳实践
bash
# ❌ 锁死版本（不同 Python 版本不兼容）
pyobjc-core==9.2
# ✅ 不指定版本（pip 自动匹配）
pyobjc-core
# ✅ 设下限
pyobjc-core>=9.0为什么不锁版本:
你用 Python 3.11 开发锁了 ==9.2，用户用 Python 3.13 安装就失败（9.2 没有 3.13 的 wheel）。不指定版本，pip 自动选最佳兼容版本。
5. 选择开源协议
| 协议 | 一句话理解 | 对用户的要求 | 适合场景 |
|---|---|---|---|
| MIT | "随便用，随便改，随便卖，只要保留版权声明" | 无强制开源要求 | 新手首选：工具类、库、小项目 |
| Apache 2.0 | "和 MIT 类似，但明确保护专利" | 无强制开源，但要声明修改内容 | 企业级项目、涉及专利的技术 |
| GPL 3.0 | "你用我的代码，你的项目也得开源" | 衍生作品必须开源（传染性） | 希望推动整个生态开源的理想主义者 |
新手建议：选 MIT 就够了。不确定用哪个？MIT 就对了。
6. CONTRIBUTING.md 要写什么
主要为想一起共建的朋友说明规范，该如何一起共建，提Issue规范、提PR规范、提交的代码规范等
bash
# 贡献指南
感谢你愿意为 [项目名称] 做贡献！🎉
## 欢迎哪些贡献？
- 报告 Bug（提交 Issue）
- 修复 Bug（提交 PR）
- 增加新功能
- 改进文档
- 优化代码风格
## 行为准则
请遵守我们的 [行为准则](CODE_OF_CONDUCT.md)（简单说：友善、尊重）。
## 如何提交 Issue？
1. 先搜索是否已有类似 Issue
2. 使用提供的模板：描述问题、复现步骤、环境信息
3. 标签选择：`bug` / `enhancement` / `question`
## 如何提交代码（PR）？
1. **Fork 本项目** → 点击 GitHub 右上角 Fork 按钮
2. **克隆你的 Fork**：`git clone https://github.com/你的用户名/项目名.git`
3. **创建分支**：`git checkout -b feat/你的功能名`（不要直接在 main 上改）
4. **写代码 + 写测试**（如果项目有测试）
5. **运行测试**：确保全部通过
6. **提交信息规范**：`feat: 添加xxx功能` / `fix: 修复xxx问题`
7. **推送到你的仓库**：`git push origin feat/你的功能名`
8. **在 GitHub 上发起 Pull Request** → 选择 `main` 作为目标分支
9. 等待 Review
## 代码规范
- 语言/框架：[例如 Python 3.9+]
- 风格：[例如 遵循 PEP 8 / Prettier 默认配置]
- 注释：重要逻辑用英文或中文写清"为什么"
- 测试：新功能必须附带测试用例
## 开发环境搭建
```bash
git clone https://github.com/原项目地址.git
cd 项目名
# 安装依赖（示例）
pip install -r requirements.txt
# 运行测试
python -m pytest tests/本节小结
- README.md 按"用户优先"顺序编写
- 有 LICENSE（MIT）
- 有 build.sh 一键脚本
- requirements.txt 不锁版本
- 有 CONTRIBUTING.md
第 05 节：发布上线
1. 完整发布流程
bash
代码写完 → Git 初始化 → 推到 GitHub → 打标签 → 发布 Release（附带预编译包）2. 初始化 Git
bash
cd yiq-guard
git init
git add .
git status # 确认没有敏感文件
git commit -m "feat: initial release of yiq-guard v1.1"
Commit 信息规范:
| 前缀 | 用途 | 示例 |
|---|---|---|
| feat: | 新功能 | feat: add double-press mode |
| fix: | 修 Bug | fix: focus not returning after cancel |
| docs: | 文档 | docs: update README install section |
| refactor: | 重构 | refactor: extract hotkey config |
| test: | 测试 | test: add event tap unit tests |
| chore: | 杂项 | chore: update .gitignore |
3. 推送到 GitHub
gh是Github cli工具，可以创建仓库，提交PR，发布release等，可通过brew命令直接安装。
bash
# 创建仓库
gh repo create ziyifast/yiq-guard --public --description "macOS 防误触 Cmd+Q 守护工具"
git remote add origin https://github.com/ziyifast/yiq-guard.git
# 创建分支
git branch -M main
# 推送
git push -u origin main
仓库设置：
在 GitHub 仓库页面：
- About → 一句话描述
- Topics →
macos,python,keyboard,utility,menu-bar,productivity - Social Preview → 项目封面图（1280×640px）
4. 预编译分发
为什么要发布预编译包
bash
源码分发：用户需要 Python + pip + venv + 打包 → 80% 的人在这一步放弃
预编译分发：下载 → 解压 → 拖进 Applications → 30 秒搞定py2app 打包的 .app 是自包含的------内含 Python 运行时 + 所有依赖。用户不需要安装任何东西。
打包步骤
bash
# 方式一：用脚本（推荐）
bash release.sh
# 输出: release/yiq-guard-v1.1.0-macOS.zip
# 方式二：手动
bash build.sh # 打包
codesign --deep --force --sign "-" dist/yiq-guard.app # 签名
zip -r yiq-guard-v1.1.0-macOS.zip dist/yiq-guard.app # 压缩
5. 发布 Release
可以通过gh命令直接发布release或者在Github上通过页面手动操作也可以
bash
# 打标签
git tag -a v1.1.0 -m "v1.1.0"
git push origin v1.1.0
# 创建 Release 并上传
gh release create v1.1.0 release/yiq-guard-v1.1.0-macOS.zip \
--title "v1.1.0" \
--notes "## 安装
1. 下载 yiq-guard-v1.1.0-macOS.zip
2. 解压 → 将 yiq-guard.app 拖入 /Applications
3. 首次打开：右键 → 打开
4. 授权辅助功能权限
## 从源码构建
\`\`\`bash
git clone ... && cd yiq-guard && bash build.sh
\`\`\`"
Release 结构
bash
v1.1.0 Release
├── yiq-guard-v1.1.0-macOS.zip ← 普通用户下载
├── Source code (zip) ← GitHub 自动生成
└── Source code (tar.gz) ← GitHub 自动生成6. Gatekeeper 问题
Gatekeeper 是 macOS 中的一项安全机制，它会阻止没有通过 Apple 审核的应用程序运行。用户首次打开会提示"无法验证开发者"。
默认情况下，Gatekeeper 只允许安装来自 Mac App Store 或 经过 Apple Developer ID 认证的开发者 的应用程序。
PS：因为本身一开始就只是我个人使用，所以我没申请苹果开发者。同时 Apple Developer 证书（$99/年）
在 Release Notes 中告知解决方法：
bash
首次打开提示"无法验证"？
→ 右键点击 yiq-guard.app → 选择"打开"
→ 或终端: xattr -cr /Applications/yiq-guard.app
或者执行：sudo spctl --global-disable7. 版本号规范（SemVer）
bash
v主版本.次版本.补丁
v1.2.3
主版本（1）：不兼容的破坏性改动
次版本（2）：向后兼容的新功能
补丁版本（3）：Bug 修复8. 推广项目
如果觉得合适也可以给自己的项目弄一个官方，看起来更专业和正式。
| 平台 | 适合 |
|---|---|
| V2EX | 极客圈，效率工具爆发力强 |
| 少数派 | macOS 工具首选 |
| 掘金 | 技术社区 |
| Reddit r/macapps | 国际用户 |
| Hacker News | 极客流量 |
| Product Hunt | 全球产品发布，能获得国际曝光 |
推广文章结构:
bash
标题：我写了一个防误触 Cmd+Q 的 macOS 小工具（开源）
1. 痛点故事（引起共鸣）
2. 解决方案 + 效果 GIF
3. 技术亮点
4. GitHub 链接
5. 未来计划本节小结
- 代码已推送到 GitHub
- 仓库 Description 和 Topics 已设置
- 打了版本标签
- Release 中附带预编译 .app
- Release Notes 包含安装说明
- 在至少一个社区发布了介绍
第 06 节：实战复盘 --- yiq-guard 的 6 次迭代
这一节不是让你"照做"，而是让你建立一个心理预期：你的项目也会经历类似的迭代。提前知道这些坑，能让你踩得更从容。下面是我 yiq-guard 从 v1.0 到 v1.1 的 6 次真实迭代。
迭代 1：最小可用版本
目标：证明核心技术可行 + 跑通闭环
产出：
- ✅ CGEventTap 拦截 Cmd+Q
- ✅ 弹窗确认模式
- ✅ 双击确认模式（0.8s）
- ✅ 菜单栏常驻
- ✅ 配置持久化
经验：不要追求完美，先让它能用。发布一个 60 分的东西，比永远停留在"还没准备好"好一万倍。
迭代 2：品牌化
改动：
- 项目名 CmdQGuard → yiq-guard
- 包名 cmdqguard → yiq-guard
- Bundle ID → com.ziyi.yiq-guard
- 生成品牌图标
- 补全 README / LICENSE / CONTRIBUTING
经验：品牌化不是浪费时间。统一的命名让项目显得专业，用户更愿意信任和使用。
迭代 3：快捷键冲突
测试过程："按 Option+Shift+Q 打开设置时，会输入 Œ 字符！"
根因：macOS 中 Option+Shift+Q 是输入特殊字符的系统快捷键。
修复：
- 默认改为 Ctrl+Option+Q（不产生字符）
- 新增快捷键可配置功能
经验：永远在真机上测试快捷键。不同键盘布局、系统版本有意想不到的冲突。开发机上能用 ≠ 用户机上能用。
迭代 4：退出体验
测试反馈："我不小心把 yiq-guard 退出了，完全没有感知！退出的确认框和退出普通应用一模一样。"
问题：退出确认弹窗太普通，和"确认退出 Excel"长得一样。
修复：
- 改为 Critical 样式（⚠️ 大图标 + 红色警告）
- 默认按钮改为"取消"（防止习惯性点第一个按钮）
- 弹窗文案列举退出后果
经验：工具类应用退出 ≠ 普通应用退出。要有仪式感和区分度。
迭代 5：焦点穿透
用户反馈："确认对话框出现后，焦点跑到了 yiq-guard。再按 Cmd+Q 退出的是 yiq-guard 而不是 Excel！"
问题复现：
bash
Excel 中按 Cmd+Q
→ 弹出确认框（焦点转移到 yiq-guard）
→ 用户点"取消"
→ 焦点留在 yiq-guard（不回 Excel）
→ 再按 Cmd+Q
→ 退出的是 yiq-guard！修复：
- 取消后自动恢复焦点到原应用
- 焦点在 yiq-guard 时 Cmd+Q 不退出，只显示提示
- yiq-guard 永远不会被自己的保护机制退出
经验：菜单栏应用的焦点管理是 macOS 开发中最容易踩的坑。
对话框会抢焦点，必须手动还回去。
迭代 6：功能完善
改动：
- 菜单栏退出按钮（带 Critical 确认）
- 退出快捷键 Ctrl+Option+Shift+Q（可配置）
- 设置面板新增快捷键编辑区域
- 启动时 Toast 通知
- 双击间隔从 0.8s → 1.5s
经验：给用户控制权。可配置 > 硬编码。但不要过度配置------默认值要足够好，80% 的用户不会改设置。