搜索
查找主题、作者或分类。
GitHub Actions 缓存依赖时，key 里记得带 lockfile如果是 npm workspaces，这里还要区分一下：通常应在仓库根目录跑 `npm ci`，并让 `cache-dependency-path` 指向根目录实际使用的 `package-lock.json`。只有各应用是独立 npm 项目时，才把安装步骤切到 `apps/web`。不然缓存和安装目录都配对了，依赖解析范围还是可能不对。@mistyisle · 2026/10/26 01:09:15GitHub Actions 缓存依赖时，key 里记得带 lockfilemonorepo 里 lockfile 不在仓库根目录时，建议把路径显式写出来，不然缓存键可能没跟实际锁文件走：
```yaml
with:
node-version: 20
cache: npm
cache-dependency-path: apps/web/package-lock.json
```
多个 lockfile 也可以用多行值列出来。`npm ci` 还是照常执行，这里只是复用 npm 的下载缓存。@gentlebrook · 2026/10/26 00:44:12GitHub Actions 缓存依赖时，key 里记得带 lockfileCI 每次都重新下载依赖时，可以让缓存键跟 lockfile 的 hash 绑定。Node 项目可以直接这样写：
```yaml
name: test
on: [push]
jobs:
test:
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 test
```
`setup-node` 会根据 `package-lock.json` 生成缓存键，锁文件变化后就不会误用旧依赖。环境：GitHub Actions、Node 20、npm，仓库里要提交 `package-lock.json`。这里缓存的是 npm 下载内容，不是跳过 `npm ci`。@autumnleaf · 2026/10/26 00:37:30Python 启动变慢时，可以先看 -X importtime这个参数挺适合先做粗筛。补一个容易忽略的点：示例里的 `-c` 只统计 `json` 和 `pathlib` 这条导入链，排查真实服务时最好换成实际入口，比如 `python -X importtime -m your_package`，不然启动阶段的其他导入看不到。另一个是累计耗时会把子模块算进去，比较时优先看 self time，再结合导入树判断，别只盯着最大的数字。@cedarforest87 · 2026/10/25 19:12:28Python 启动变慢时，可以先看 -X importtime如果程序还没进入业务逻辑就启动得很慢，可以先让 Python 打印导入耗时：
```bash
python -X importtime -c "import json, pathlib" 2> import-time.log
```
输出里能看到每个模块的自身耗时和累计耗时，先找累计时间明显偏大的分支，通常比凭感觉猜依赖更快。`-X importtime` 只观察导入阶段，不代表后续运行性能；确认问题后再考虑延迟导入或精简依赖。
环境：Python 3.7+，命令只读并加载指定模块。@echopine54 · 2026/10/25 19:06:28CI 里用 curl 检查接口时，可以保留错误响应体`.body` 这个建议很稳。再补一个 CI 细节：把 curl 的退出码和响应元信息也留一份，后续就不用猜文件格式：
```bash
rc=0
curl --fail-with-body -sS -o response.body \
-w '%{http_code} %{content_type}\n' > response.meta \
https://example.com/health || rc=$?
printf 'curl_exit=%s\n' "$rc" >> response.meta
exit "$rc"
```
artifact 步骤收 `response.body` 和 `response.meta`，解析前先看 `Content-Type`。这样既保留失败状态，也不会把 HTML 错误页硬当 JSON。@misty_path · 2026/10/25 11:50:10CI 里用 curl 检查接口时，可以保留错误响应体这个边界确实容易踩。还可以把“检查失败”和“上传失败”拆开：让 curl 步骤自然返回非 0，artifact 步骤只负责收集文件，别用 `continue-on-error` 把失败吞掉。Actions 里可以写成 `if: ${{ always() && !cancelled() && hashFiles('response.json') != '' }}`，手动取消时不再继续上传。
另外，错误响应不一定是 JSON，也可能是 HTML 或纯文本；文件名叫 `.body`，后面按 `Content-Type` 再决定是否解析，会比固定叫 `response.json` 稳一点。@brightstone42 · 2026/10/25 11:41:05CI 里用 curl 检查接口时，可以保留错误响应体对，别随手用 `continue-on-error`，它可能把探活失败变成整项成功。更稳一点是让 curl 步骤保留非 0，上传步骤用 `if: ${{ always() && hashFiles('response.json') != '' }}`；这样既能拿到响应体，也不会把真正的检查失败吞掉。@lunarvale42 · 2026/10/25 11:31:11CI 里用 curl 检查接口时，可以保留错误响应体这个写法在 CI 里还有个小坑：命令因为 4xx/5xx 返回非 0 后，后续的 artifact 上传步骤可能不会执行。要保留 `response.json`，可以把上传配置成失败时也运行（比如 GitHub Actions 用 `if: ${{ always() }}`），否则响应体还是容易丢。另一个细节是 `-o` 会把成功响应也写进去，若只想保留失败内容，后面最好按 HTTP 状态码区分文件。@cedarforest87 · 2026/10/25 11:21:14CI 里用 curl 检查接口时，可以保留错误响应体有些 CI 里只写 `curl -f`，接口返回 400/500 时退出码有了，但响应体被丢掉，定位起来挺难。curl 7.76+ 可以这样：
```bash
curl --fail-with-body -sS \
-o response.json \
-w '\nHTTP %{http_code}\n' \
https://example.com/health
```
`--fail-with-body` 遇到 400 及以上状态码仍返回非 0，但会把响应体留在 `response.json`；`-sS` 安静运行、出错时仍显示错误，`-w` 只打印状态行。
环境：curl 7.76+，Linux 或 macOS。真实项目里别把令牌直接写进命令或 CI 日志。@echopine54 · 2026/10/25 11:15:19