开发笔记 on 武成龙

Apifox 调试 SSE 接口

Wed, 05 Aug 2026 00:00:00 +0000

SSE 广泛用于 AI 流式响应。Apifox（≥2.3.10）原生支持：

新建 HTTP 接口，填写地址、设置返回类型后发送。
返回 text/event-stream 时自动解析 SSE 事件。
时间线视图实时查看，内置 OpenAI / Gemini / Claude 格式自动合并。
自定义格式配置 JSONPath 提取规则，或用后置脚本处理。

参考：Apifox 官方文档 - SSE 调试

Zed自定义Git命令

Fri, 31 Jul 2026 00:00:00 +0000

Zed自定义Git命令

适用环境：Zed 编辑器 + Git Graph / Git Panel · 配置位置：~/.config/zed/tasks.json

一、核心结论

用 tags: ["git-command"] 定义任务，配合 $ZED_GIT_* 变量，把「查看、派生、分支操作」三类高频 Git 操作变成右键即用的菜单命令，从此告别手敲 SHA 和分支名。

一份配置，三个收益：

零记忆：不用记 SHA、不用复制粘贴，右键即点即用
零输入：分支名 / 标签名 / 提交号全部由变量自动注入
零切换：不离开编辑器，git 操作全部在 Zed 的终端里完成

二、三大机制

理解这三件事，后面所有配置都是它们的排列组合。

2.1 入口：命令从哪来

任务定义在全局 tasks.json（工作区级 .zed/tasks.json 暂不支持）
带 git-command 标签的任务会出现在 Git Graph 的右键菜单里：
- 右键提交行 → 提交菜单（Commit 菜单）
- 右键分支 / 远程引用 / 标签 chip → 引用菜单（Ref 菜单）

2.2 变量：能自动注入什么

变量	含义	可用菜单
`$ZED_GIT_SHA`	选中提交的完整 SHA	Commit + Ref
`$ZED_GIT_SHA_SHORT`	短 SHA（7 位）	Commit + Ref
`$ZED_GIT_REPOSITORY_NAME`	仓库名	Commit + Ref
`$ZED_GIT_REPOSITORY_PATH`	仓库绝对路径（默认 cwd）	Commit + Ref
`$ZED_GIT_REF`	点击的引用名（分支/远程/标签）	仅 Ref 菜单

编辑器类变量（$ZED_FILE、$ZED_SELECTED_TEXT 等）在 Git 任务里不会提供，引用它们的任务会被自动过滤。

2.3 过滤规则：任务怎么"隐身"

任务里用了 $ZED_GIT_REF → 只在右键 chip 时出现
任务里只用 $ZED_GIT_SHA → 提交菜单和引用菜单都出现
任务不用任何变量 → 两种菜单都出现
任务用了不存在的变量 → 不出现

结论：用变量本身做"菜单路由"，想限定场景就引用对应变量。

三、三种写法与两个大坑

3.1 三种写法

写法	适用场景	示例
A. 纯参数：`command` + `args`	参数无空格、无特殊字符	`git branch -d $ZED_GIT_REF`
B. 整行命令：整条 shell 命令放 `command`	含管道 / 重定向 / 交互输入	`git show $ZED_GIT_SHA \| pbcopy`
C. tty 交互：`/dev/tty` + `read`	需要现场输入（起名 / 改名）	见 3.3

3.2 大坑一：args 会被"拆碎"

Zed 会把 command 和所有 args 用空格拼成一条命令行交给登录 shell 执行，不负责转义。所以：

"args": ["-c", "printf 'Branch name: ' > /dev/tty; ..."]

拼接后变成 zsh -c printf 'Branch name: ' > /dev/tty; ...，-c 后面只跟了 printf 一个词 → 报 zsh: printf:1: not enough arguments。

对策：含空格/引号/特殊符号的命令一律用写法 B（整行命令），让登录 shell 原样执行，不经过拼接。

3.3 大坑二：交互输入要绑 `/dev/tty`

任务跑在 PTY 里，标准输入不一定是终端。输入提示的标准姿势：

{
 "label": "Create tag at: $ZED_GIT_SHA_SHORT",
 "command": "printf 'Tag name: ' > /dev/tty; IFS= read -r name < /dev/tty; [ -n \"$name\" ] && git tag \"$name\" \"$ZED_GIT_SHA\"",
 "tags": ["git-command"]
}

三段式：打印提示到 tty → 从 tty 读入 → 非空才执行。注意这里整行命令在 command 字段，天然规避了大坑一。

3.4 平台差异

pbcopy（复制到剪贴板）仅 macOS；Linux 换 xclip -selection clipboard 或 wl-copy
open -a Fork 依赖 Fork 应用，其他平台可换成 GitHub/GitLab 链接

四、命令清单

4.1 提交右键族（Commit 菜单）—— 看、取、派、查

命令	作用	备注
Cherry-pick	摘取提交	已有基础版；`-x` 版会记录来源
Revert	撤销提交	已有；`-m 1` 版专用于合并提交
Show	查看提交 + 文件统计	`git show --stat`
Diff vs parent	只看该提交的改动	`git diff sha^ sha`
Branches containing	哪些分支包含此提交	排查漏合并神器
Copy patch	整段 patch 进剪贴板	macOS 需 `pbcopy`
Create fixup	对旧提交打补丁标记	配合 `rebase --autosquash`
Create tag at	在提交上打标签	tty 交互输入
Bisect bad / good	二分定位回归	右键提交直接标记

4.2 分支标签右键族（Ref 菜单）—— 引用的增删改查

命令	作用	备注
Delete branch	删除本地分支	`-d` 仅删已合并，`-D` 强删
Delete tag	删除本地标签	可选配"删远程标签"版
Check out	切换分支	官方示例同款
Merge	并入当前分支	注意当前分支被保护
Rebase onto	当前分支变基到它
Diff vs HEAD	与当前分支的差异统计
Log	看该引用最近 15 条	`--graph` 带拓扑
Push -u origin	推送并建立上游	新建分支后常用
Rename	重命名分支	tty 交互输入

4.3 通用族（两种菜单都会出现）—— 谨慎添加

git status、git fetch --prune 这类无变量任务两种菜单都显示，容易把菜单刷爆，按需添加。

五、完整配置（可直接粘贴）

合并进 ~/.config/zed/tasks.json 的数组里即可。其中 Create branch at 已修复为整行写法（规避大坑一）。

[
 { "label": "Cherry-pick", "command": "git", "args": ["cherry-pick", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Cherry-pick (-x): $ZED_GIT_SHA_SHORT", "command": "git", "args": ["cherry-pick", "-x", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Revert", "command": "git", "args": ["revert", "--no-edit", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Revert merge: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["revert", "-m", "1", "--no-edit", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Show: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["show", "--stat", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Branches containing: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["branch", "-a", "--contains", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Diff vs parent: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["diff", "$ZED_GIT_SHA^", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Create fixup: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["commit", "--fixup", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Copy patch: $ZED_GIT_SHA_SHORT", "command": "git show $ZED_GIT_SHA | pbcopy", "tags": ["git-command"] },
 {
 "label": "Create tag at: $ZED_GIT_SHA_SHORT",
 "command": "printf 'Tag name: ' > /dev/tty; IFS= read -r name < /dev/tty; [ -n \"$name\" ] && git tag \"$name\" \"$ZED_GIT_SHA\"",
 "tags": ["git-command"]
 },
 { "label": "Bisect bad: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["bisect", "bad", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Bisect good: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["bisect", "good", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 {
 "label": "Create branch at: $ZED_GIT_SHA_SHORT",
 "command": "printf 'Branch name: ' > /dev/tty; IFS= read -r name < /dev/tty; [ -n \"$name\" ] && git branch \"$name\" \"$ZED_GIT_SHA\"",
 "tags": ["git-command"],
 "reveal": "always",
 "use_new_terminal": true
 },
 {
 "label": "Open in Fork",
 "command": "zsh",
 "args": ["-c", "open -a Fork . && sleep 2 && open \"fork://repo/$ZED_GIT_REPOSITORY_NAME/commit/$ZED_GIT_SHA\""],
 "tags": ["git-command"]
 },
 { "label": "Reset --soft to: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["reset", "--soft", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Reset --hard to: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["reset", "--hard", "$ZED_GIT_SHA"], "tags": ["git-command"] },

 { "label": "Delete branch: $ZED_GIT_REF", "command": "git", "args": ["branch", "-d", "$ZED_GIT_REF"], "tags": ["git-command"] },
 { "label": "Delete tag: $ZED_GIT_REF", "command": "git", "args": ["tag", "-d", "$ZED_GIT_REF"], "tags": ["git-command"] },
 { "label": "Delete remote tag: $ZED_GIT_REF", "command": "git", "args": ["push", "origin", "--delete", "refs/tags/$ZED_GIT_REF"], "tags": ["git-command"] },
 { "label": "Check out: $ZED_GIT_REF", "command": "git", "args": ["checkout", "$ZED_GIT_REF"], "tags": ["git-command"] },
 { "label": "Merge: $ZED_GIT_REF", "command": "git", "args": ["merge", "$ZED_GIT_REF"], "tags": ["git-command"] },
 { "label": "Rebase onto: $ZED_GIT_REF", "command": "git", "args": ["rebase", "$ZED_GIT_REF"], "tags": ["git-command"] },
 { "label": "Diff vs HEAD: $ZED_GIT_REF", "command": "git", "args": ["diff", "--stat", "HEAD", "$ZED_GIT_REF"], "tags": ["git-command"] },
 { "label": "Log: $ZED_GIT_REF", "command": "git", "args": ["log", "--oneline", "--graph", "-15", "$ZED_GIT_REF"], "tags": ["git-command"] },
 { "label": "Push -u origin: $ZED_GIT_REF", "command": "git", "args": ["push", "-u", "origin", "$ZED_GIT_REF"], "tags": ["git-command"] },
 {
 "label": "Rename: $ZED_GIT_REF",
 "command": "printf 'New name: ' > /dev/tty; IFS= read -r name < /dev/tty; [ -n \"$name\" ] && git branch -m \"$ZED_GIT_REF\" \"$name\"",
 "tags": ["git-command"]
 }
]

六、收尾：三条心法

写法优先：拿不准就整行写 command，别跟 args 拼接较劲
变量即路由：菜单放哪，由变量决定，别硬塞
标签醒目：Delete branch: / Delete tag: 前缀写清楚，右键前瞄一眼就不手滑

记得刷新Git树验证命令效果，如tag添加和删除需要刷新后才能看到效果。

参考资料

Zed Docs — Custom Git Commands — 官方文档，涵盖 git-command 标签、Git 专属变量（$ZED_GIT_SHA、$ZED_GIT_REF 等）、变量过滤规则和示例配置。

接手老旧项目不用改公共gitignore：用git exclude静默忽略AI配置文件

Fri, 24 Jul 2026 00:00:00 +0000

接手老旧项目不用改公共gitignore：用git exclude静默忽略AI配置文件

接手维护年代久远的历史项目时，很多人会借助 Coding Agent （例如Claude Code，Codex）生成 CLAUDE.md、AGENT.md，用来定制本地代码辅助规则。这类文件只服务于我个人本地AI开发，不需要同步给团队、不能提交到远程仓库。但历史仓库的 .gitignore 是团队统一维护的，随意新增规则会打乱原有规范，不适合修改；全局gitignore又会让所有项目都屏蔽这两个文件，灵活性太差。

这时最佳方案：使用 git exclude。

极简使用步骤

进入项目根目录，创建对应目录（不存在则自动新建）

mkdir -p .git/info

编辑私有忽略文件 .git/info/exclude，写入两行规则

CLAUDE.md
AGENT.md

保存后即时生效，无需额外Git命令。

核心优势

文件存放在 .git 目录内，不会被Git追踪、推送远程，仅当前本地这份仓库生效；
全程不动仓库里任何公开文件，.gitignore 零改动，不会影响团队所有人；
语法和gitignore完全一致，上手无学习成本。

简单选型对比

项目.gitignore：改公共配置，全员生效，适合团队通用文件，此处不合适；
全局gitignore：全电脑所有仓库统一屏蔽，会误伤其他需要保留CLAUDE.md的项目；
git exclude：单仓库、个人私有屏蔽，完美适配本地AI配置。

结尾小结

所有仅自己使用、不方便改动团队忽略清单的本地文件，优先交给git exclude管理。

用Code Server随时随地打开你的VS Code

Fri, 24 Jul 2026 00:00:00 +0000

用Code Server随时随地打开你的VS Code

想把家里电脑变成一个永远在线的开发环境，出门用 iPad、公司电脑、酒店商务机，只要能上网就能打开「自己那台 VS Code」继续写代码？开源项目 code-server 就是干这个的：它在你的电脑上跑一个服务，把完整的 VS Code 编辑器通过浏览器渲染出来，任何联网设备打开网址就是熟悉的编辑器界面。

下面按「需求描述 → 解决方案 → 配置过程」三步走。

需求描述

典型场景很明确：

代码、环境、插件、终端全都装在自己电脑上，不想到处同步；
不想被设备绑死——iPad、别人的 Mac、网吧 Windows，只要能开浏览器就想直接接着写；
不想为了"换个地方写代码"去买云服务器、搞 SSH 隧道、装客户端。

换句话说，目标是：把电脑上的 VS Code 变成一个网址，任何联网设备访问即用。

解决方案

code-server 会以服务形式跑在你的电脑上，监听一个端口，对外提供 HTTPS 的编辑器页面。访问端不需要装任何东西，浏览器即是客户端。

对外暴露服务时需要一张 SSL 证书，让浏览器走 https:// 而不是被拦截的 http://。code-server 官方在文档里给出了几种证书路线，其中最省事的是 自签名证书（self-signed certificate），前提是：

你的电脑（实例）需要能被互联网访问到；
你不想买域名、也不想用 SSH 端口转发。

需要提前知道自签名证书的几个限制（来自官方文档，务必留意）：

iPad 不支持自签名证书，iPad 上直接访问会失败，详细情况见官方 ipad.md；
自签名证书可能给 code-server 带来一些意外的小问题；
因此官方把它定位成「最后手段（last resort）」——只有在你确实不想买域名 / 无法做端口转发时才用。

如果你能接受这些限制，自签名这条路就足够轻量，继续看配置过程。

配置过程

以下命令基于 code-server 官方文档，目标是在电脑（实例）上启用自签名证书、监听 443 端口，然后通过 https://<你的IP> 访问。

1. SSH 进入你的电脑 / 实例

确认这台机器对公网开放了 HTTP/HTTPS 流量（防火墙、安全组放行 443）。

2. 修改 code-server 配置

code-server 的配置文件在 ~/.config/code-server/config.yaml。用官方给的两条 sed 一键改：开启自签名证书、把监听地址从本机回环改成全网卡 + 443 端口。

# 把 "cert: false" 改成 "cert: true"
sed -i.bak 's/cert: false/cert: true/' ~/.config/code-server/config.yaml
# 把 "bind-addr: 127.0.0.1:8080" 改成 "bind-addr: 0.0.0.0:443"
sed -i.bak 's/bind-addr: 127.0.0.1:8080/bind-addr: 0.0.0.0:443/' ~/.config/code-server/config.yaml
# 允许 code-server 监听 443 这个特权端口
sudo setcap cap_net_bind_service=+ep /usr/lib/code-server/lib/node

sed -i.bak 会同时生成一个 .bak 备份，方便回滚。

3. 重启 code-server

sudo systemctl restart code-server@$USER

4. 浏览器访问

现在在任意联网设备的浏览器里打开：

https://<你的实例IP>

就会看到 code-server 的登录页，输入 config.yaml 里的密码即可进入编辑器。

5. （可选）消除自签名证书的浏览器警告

自签名证书浏览器会报「不安全」并弹警告。官方推荐用 mkcert 生成一张被本机操作系统信任的自签名证书，然后把证书路径填进 code-server 配置里的 cert 和 cert-key 两个字段即可消除警告。

注意：mkcert 让本机信任这张证书，并不等于让 iPad / 其他设备也信任。跨设备无警告访问仍然需要一张正规证书（域名 + Let’s Encrypt 等）。

小结

code-server = 把本机 VS Code 变成网址，浏览器即客户端；
自签名证书路线最省事，但 iPad 不支持、可能伴随小问题，仅当不想买域名 / 不想端口转发时使用；
核心就改两行配置（cert: true、bind-addr: 0.0.0.0:443）+ 一条 setcap + 重启，之后 https://<IP> 即可访问。

Monorepo 按变更自动部署

Fri, 10 Jul 2026 00:00:00 +0000

Monorepo 项目的按变更自动部署

当一个仓库里放了多个子项目，它们共享同一套底层代码，每次推送如果全部重新构建和部署，既慢又浪费构建额度。更好的做法是：改了哪个项目，就只部署哪个项目。

共享代码的困境

典型的 monorepo 目录结构：

my-project/
├── apps/
│ ├── web/ # 主站
│ ├── admin/ # 后台
│ └── docs/ # 文档站
├── packages/
│ ├── shared-ui/ # 公共组件
│ └── utils/ # 工具函数
└── package.json

apps/ 下的三个项目都依赖 packages/ 里的公共代码。公共代码一改，三个项目都可能受影响；但只改 admin 的业务页面，web 和 docs 就没必要动。

思路

在 GitHub Actions 里加一个"变更检测"步骤，判断这次提交改了哪些目录。如果只改了 apps/web，就只构建和部署 web；如果改了 packages/utils，所有依赖它的项目都触发部署。

推送代码 → 检测哪些目录变了 → 只构建和部署变更涉及的项目 → 未变更的跳过

示例

name: Deploy

on:
 push:
 branches: [main]

jobs:
 # 第一步：检测变更
 detect-changes:
 runs-on: ubuntu-latest
 outputs:
 web: ${{ steps.changes.outputs.web }}
 admin: ${{ steps.changes.outputs.admin }}
 docs: ${{ steps.changes.outputs.docs }}
 steps:
 - uses: actions/checkout@v4
 with:
 fetch-depth: 0

 - uses: dorny/paths-filter@v2
 id: changes
 with:
 filters: |
 web:
 - 'apps/web/**'
 - 'packages/**'
 admin:
 - 'apps/admin/**'
 - 'packages/**'
 docs:
 - 'apps/docs/**'
 - 'packages/**'

 # 第二步：按条件部署
 deploy-web:
 needs: detect-changes
 if: needs.detect-changes.outputs.web == 'true'
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 # ... 构建和部署 web

 deploy-admin:
 needs: detect-changes
 if: needs.detect-changes.outputs.admin == 'true'
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 # ... 构建和部署 admin

 deploy-docs:
 needs: detect-changes
 if: needs.detect-changes.outputs.docs == 'true'
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 # ... 构建和部署 docs

关键设计

变更规则怎么写

每个子项目的 filters 要同时包含自己的目录和公共包目录：

filters: |
 web:
 - 'apps/web/**' # 自己的业务代码
 - 'packages/**' # 公共依赖
 admin:
 - 'apps/admin/**'
 - 'packages/**'

这样公共包一改，所有子项目都会触发部署，不会遗漏。

如果公共包内部也可以区分为"仅 A 项目用"和"B、C 共用"，可以写得更细：

filters: |
 web:
 - 'apps/web/**'
 - 'packages/shared-ui/**'
 - 'packages/utils/**'
 admin:
 - 'apps/admin/**'
 - 'packages/utils/**'

条件跳过

通过 needs 拿到上一步的输出结果，用 if 决定是否执行：

deploy-admin:
 needs: detect-changes
 if: needs.detect-changes.outputs.admin == 'true'

没变化的项目这个 Job 直接跳过，不浪费 CI 时间。

支持手动全量部署

加一个手动触发入口，允许绕开变更检测，强制部署所有项目：

on:
 push:
 branches: [main]
 workflow_dispatch:
 inputs:
 deploy_all:
 description: '强制全量部署'
 type: boolean
 default: false

然后在 Job 的条件里加判断：

if: |
 needs.detect-changes.outputs.admin == 'true' ||
 github.event.inputs.deploy_all == 'true'

前端自动部署模式对比

Fri, 10 Jul 2026 00:00:00 +0000

前端自动部署的几种方式

维护项目的一大痛点就是希望推送代码后自动触发更新部署，对此可以采用 GitHub Actions 设置自动部署的工作流（Workflow），对于前端来说有三种主流做法：

	直传文件	服务器构建	推送仓库拉取
构建位置	CI	服务器	CI
传输内容	静态产物	完整源码	镜像
服务器需装	Web 服务	Docker + 构建工具	仅 Docker
多服务器部署	逐个上传	逐个构建	各自拉取同一镜像
回滚方式	切备份目录	切旧镜像	拉指定 tag 镜像
主要局限	只能静态文件	服务器负担重、多台不一致	需维护镜像仓库

三种模式遵循同一个核心逻辑：构建 → 替换线上 → 出问题可回退。区别只在于构建在哪发生、中间产物是什么。

模式一：CI 构建 + 直传文件

思路

这是最直接的方式。在 CI 里装依赖、跑构建，把产出的静态文件传到服务器站点目录，用新旧目录互换上线。但它的前提是：构建产物是静态文件，丢到 Web 服务器就能跑。如果项目需要以容器方式运行，光传文件没用，得走 Docker 构建。

流程

推送代码 → CI 构建 → SCP 传文件到服务器 → 备份旧目录 → 替换为新文件 → 刷新服务

示例

name: Deploy

on:
 push:
 branches: [main]

jobs:
 deploy:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: actions/setup-node@v4
 with:
 node-version: '20'
 cache: 'npm'

 - run: npm ci
 - run: npm run build

 - uses: appleboy/scp-action@v0.1.7
 with:
 host: ${{ secrets.HOST }}
 username: ${{ secrets.USERNAME }}
 key: ${{ secrets.PRIVATE_KEY }}
 source: 'dist/*'
 target: '/www/site/dist_new/'
 strip_components: 1

 - uses: appleboy/ssh-action@v1.0.3
 with:
 host: ${{ secrets.HOST }}
 username: ${{ secrets.USERNAME }}
 key: ${{ secrets.PRIVATE_KEY }}
 script: |
 cd /www/site
 BACKUP="backup_$(date +%Y%m%d_%H%M%S)"
 mkdir -p "$BACKUP"
 find . -maxdepth 1 -mindepth 1 ! -name 'dist_new' ! -name 'backup_*' \
 -exec mv {} "$BACKUP"/ \;
 cp -r dist_new/* . && rm -rf dist_new
 ls -dt backup_* | tail -n +6 | xargs -r rm -rf
 nginx -s reload

模式二：传源码 + 服务器构建

思路

模式一只能传最终的静态产物，碰上需要完整源码环境才能构建的项目（比如容器化部署）就行不通。模式二把整个仓库源码传到服务器，在服务器上现场构建、打包成镜像再启动。但这种方式的问题是：服务器必须装上全套构建工具，而且如果有好几台服务器，每台都得各自构建一遍，费时且结果可能不一致。

流程

推送代码 → SCP 传源码 → 服务器上构建镜像 → 停旧容器 → 启新容器

示例

name: Deploy

on:
 push:
 branches: [main]

jobs:
 deploy:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4

 - uses: appleboy/scp-action@v0.1.7
 with:
 host: ${{ secrets.HOST }}
 username: ${{ secrets.USERNAME }}
 key: ${{ secrets.PRIVATE_KEY }}
 source: '.'
 target: '/opt/project/build/'
 strip_components: 1

 - uses: appleboy/ssh-action@v1.0.3
 with:
 host: ${{ secrets.HOST }}
 username: ${{ secrets.USERNAME }}
 key: ${{ secrets.PRIVATE_KEY }}
 script: |
 cd /opt/project/build
 docker build -t my-app:latest .
 docker stop my-app 2>/dev/null || true
 docker rm my-app 2>/dev/null || true
 docker run -d --name my-app -p 3000:80 --restart=always my-app:latest
 docker image prune -f

模式三：CI 构建镜像 + 推送仓库 + 服务器拉取

思路

模式二让服务器承担了构建任务，服务器多了就成问题。模式三把构建和部署彻底分开：CI 里构建好镜像，推到镜像仓库；服务器不再参与构建，只需要拉取镜像、替换容器。这样每台服务器拿到的都是同一个镜像，构建环境统一在 CI 里，服务器只管运行。

可以考虑 GitHub Container Registry 托管镜像，其与 Actions 无缝集成，登录直接用 GITHUB_TOKEN 即可。

流程

推送代码 → CI 构建镜像 → 推送到镜像仓库 → 服务器拉取镜像 → 停旧容器 → 启新容器

示例

name: Deploy

on:
 push:
 branches: [main]

jobs:
 build-and-push:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4

 - uses: docker/login-action@v3
 with:
 registry: ghcr.io
 username: ${{ github.actor }}
 password: ${{ secrets.GITHUB_TOKEN }}

 - uses: docker/build-push-action@v5
 with:
 context: .
 push: true
 tags: |
 ghcr.io/${{ github.repository }}:latest
 ghcr.io/${{ github.repository }}:${{ github.sha }}

 deploy:
 needs: build-and-push
 runs-on: ubuntu-latest
 steps:
 - uses: appleboy/ssh-action@v1.0.3
 with:
 host: ${{ secrets.HOST }}
 username: ${{ secrets.USERNAME }}
 key: ${{ secrets.PRIVATE_KEY }}
 script: |
 docker pull ghcr.io/${{ github.repository }}:latest
 docker stop my-app 2>/dev/null || true
 docker rm my-app 2>/dev/null || true
 docker run -d \
 --name my-app \
 -p 3000:80 \
 --restart=always \
 ghcr.io/${{ github.repository }}:latest
 docker image prune -f

为 Windows 右键添加 VS Code 快捷打开方式

Sun, 19 Oct 2025 00:00:00 +0000

为 Windows 右键添加 VS Code 快捷打开方式

本文介绍如何在 Windows 右键菜单中添加使用 VS Code 快速打开文件和文件夹的方法。

共可添加三种右键菜单功能：

右键点击文件夹：在文件夹上右键，选择"通过VS Code打开"
右键点击文件：在单个文件上右键，选择"通过VS Code打开"
右键点击空白处：在文件夹内空白处右键，选择"通过VS Code打开当前文件夹"

方法有两种，直接重装 VS Code 并勾选安装选项，或者通过注册表手动添加。

方法一：重新安装 VS Code（推荐）

下载最新的 VS Code 安装包
运行安装程序时，确保勾选"将’通过Code 打开’操作添加到Windows资源管理器上下文菜单“选项
完成安装后即可在右键菜单中看到 VS Code 选项

方法二：修改注册表

如果你不想重新安装，可以通过修改注册表，分为手动添加和使用注册表文件：

手动操作：

打开注册表编辑器
- 按 Win + R 键，输入 regedit，回车
为文件夹添加右键菜单
- 导航到：HKEY_CLASSES_ROOT\Directory\shell
- 在 shell 上右键 → 新建 → 项，命名为 VSCode
- 在右侧窗口双击"默认”，输入显示的名称，如"通过VS Code打开"
- 在 VSCode 上右键 → 新建 → 项，命名为 command
- 在右侧窗口双击"默认"，输入 VS Code 的安装路径：
```
"C:\Users\你的用户名\AppData\Local\Programs\Microsoft VS Code\Code.exe" -n "%V"
```
```
"C:\Users\你的用户名\AppData\Local\Programs\Microsoft VS Code\Code.exe" -r "%V"
```
为文件添加右键菜单
- 导航到：HKEY_CLASSES_ROOT\*\shell
- 重复上述步骤 2 的操作
为文件夹空白处添加右键菜单
- 导航到：HKEY_CLASSES_ROOT\Directory\Background\shell
- 重复上述步骤 2 的操作

注意：

-n 是使用新窗囗打开，-r 是使用当前窗口打开
更改了不需要重启电脑
注意大小写，双引号（英文双引号），句号（英文）空格，路径（自身电脑 vscode 打开路径）
OpenWithVSCode 是右键显示的名称，可自行更改， command 是启动命令，不加会无法执行， Icon 是图标，也可自行更改

常见 VS Code 安装路径：

C:\Users\用户名\AppData\Local\Programs\Microsoft VS Code\Code.exe
C:\Program Files\Microsoft VS Code\Code.exe

使用注册表文件：

创建一个 .reg 文件，内容如下：

Windows Registry Editor Version 5.00

; 右键文件夹用VS Code打开
[HKEY_CLASSES_ROOT\Directory\shell\VSCode]
@="通过VS Code打开"
"Icon"="C:\\Users\\你的用户名\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe"

[HKEY_CLASSES_ROOT\Directory\shell\VSCode\command]
@="\"C:\\Users\\你的用户名\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe\" \"%V\""

; 右键文件用VS Code打开
[HKEY_CLASSES_ROOT\*\shell\VSCode]
@="通过VS Code打开"
"Icon"="C:\\Users\\你的用户名\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe"

[HKEY_CLASSES_ROOT\*\shell\VSCode\command]
@="\"C:\\Users\\你的用户名\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe\" \"%V\""

; 右键文件夹空白处用VS Code打开当前文件夹
[HKEY_CLASSES_ROOT\Directory\Background\shell\VSCode]
@="通过VS Code打开当前文件夹"
"Icon"="C:\\Users\\你的用户名\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe"

[HKEY_CLASSES_ROOT\Directory\Background\shell\VSCode\command]
@="\"C:\\Users\\你的用户名\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe\" \"%V\""

将文件保存为 .reg 格式，双击运行即可。

注意：请根据你的实际 VS Code 安装路径修改上述路径中的用户名部分。

Windows 11 右键菜单配置

在 Windows 11 中，右键菜单分为两种模式：

现代模式：右键显示简化菜单，需要点击"显示更多选项"才能看到完整菜单
经典模式：直接显示完整的传统右键菜单

使用传统的注册表方法无法直接添加到现代菜单中，导致 VS Code 选项只出现在"显示更多选项"中。对此，不想折腾的话可以直接使用 Shift + 右键打开完整菜单，或者一劳永逸地切换到经典模式。最后，还有一种待验证的方法是使用 PowerToys 工具来管理现代菜单。

切换到经典模式

打开注册表编辑器
导航到：HKEY_CURRENT_USER\Software\Classes\CLSID
新建项：{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}
在该项下新建项：InprocServer32
修改"默认"值为空字符串即可

使用 PowerToys 管理现代菜单

PowerToys（微软官方工具）：

从 GitHub 或 Microsoft Store 安装 PowerToys
在设置中寻找右键菜单管理功能
添加 VS Code 到现代菜单

开发笔记 on 武成龙

Apifox 调试 SSE 接口

Zed自定义Git命令

Zed自定义Git命令

一、核心结论

二、三大机制

2.1 入口：命令从哪来

2.2 变量：能自动注入什么

2.3 过滤规则：任务怎么"隐身"

三、三种写法与两个大坑

3.1 三种写法

3.2 大坑一：args 会被"拆碎"

3.3 大坑二：交互输入要绑 /dev/tty

3.4 平台差异

四、命令清单

4.1 提交右键族（Commit 菜单）—— 看、取、派、查

4.2 分支标签右键族（Ref 菜单）—— 引用的增删改查

4.3 通用族（两种菜单都会出现）—— 谨慎添加

五、完整配置（可直接粘贴）

六、收尾：三条心法

参考资料

接手老旧项目不用改公共gitignore：用git exclude静默忽略AI配置文件

接手老旧项目不用改公共gitignore：用git exclude静默忽略AI配置文件

极简使用步骤

核心优势

简单选型对比

结尾小结

用Code Server随时随地打开你的VS Code

用Code Server随时随地打开你的VS Code

需求描述

解决方案

配置过程

1. SSH 进入你的电脑 / 实例

2. 修改 code-server 配置

3. 重启 code-server

4. 浏览器访问

5. （可选）消除自签名证书的浏览器警告

小结

Monorepo 按变更自动部署

Monorepo 项目的按变更自动部署

共享代码的困境

思路

示例

关键设计

变更规则怎么写

条件跳过

支持手动全量部署

前端自动部署模式对比

前端自动部署的几种方式

模式一：CI 构建 + 直传文件

思路

流程

示例

模式二：传源码 + 服务器构建

思路

流程

示例

模式三：CI 构建镜像 + 推送仓库 + 服务器拉取

思路

流程

示例

为 Windows 右键添加 VS Code 快捷打开方式

为 Windows 右键添加 VS Code 快捷打开方式

方法一：重新安装 VS Code（推荐）

方法二：修改注册表

手动操作：

使用注册表文件：

Windows 11 右键菜单配置

切换到经典模式

使用 PowerToys 管理现代菜单

3.3 大坑二：交互输入要绑 `/dev/tty`