搜索
查找主题、作者或分类。
提交很多时，用 git bisect 定位是哪次改坏的在一长串提交里排查回归，不用挨个 checkout。`git bisect` 会用二分法不断缩小范围。
环境：Git 2.25+，先准备一个确认正常的提交，例如 `abc1234`：
```bash
git bisect start
git bisect bad HEAD
git bisect good abc1234
```
Git 会自动切到中间某个提交。跑完验证后，坏的标记 `git bisect bad`，正常的标记 `git bisect good`，重复几次就会指出最早的可疑提交。结束后记得回到原状态：
```bash
git bisect reset
```
如果项目有稳定的测试命令，还能用 `git bisect run npm test` 自动判断；测试命令需要以退出码 0 表示通过。@solar_cove · 2026/9/30 18:10:59用 npm outdated 先看依赖落后多少升级依赖前可以先跑一下 `npm outdated`，比直接翻 `package.json` 直观一点。
环境：Node.js 16+，npm 8+，项目根目录执行：
```bash
npm outdated
```
它会列出当前安装版本、`wanted` 版本和最新版本。`wanted` 一般受 semver 范围限制，`latest` 是仓库里的最新发布。
只想看生产依赖也可以：
```bash
npm outdated --omit=dev
```
这个命令只读，不会改 lockfile。比较适合升级前先判断是小补丁，还是已经跨了大版本，避免一上来就 `update` 把范围搞乱。@solar_cove · 2026/9/24 18:18:21用 node --run 直接跑 package.json 脚本还有个小坑：`node --run` 目前更像是直接跑脚本名，不会顺手做安装/解析包管理器那套事。
所以项目如果靠 `pnpm`、`yarn` 的 workspace 行为，或者 README 里要给新人复制命令，我感觉还是写原来的 `pnpm test` / `npm run test` 更不容易误会。本地自己用别名倒是挺舒服。@northbreeze21 · 2026/9/24 16:31:42用 node --run 直接跑 package.json 脚本这个在 CI 里要稍微注意一下 Node 版本。
如果脚本本身还要依赖 npm 注入的一些环境变量，先用 `node --run env` 之类的小脚本看一下也比较稳。平时本地跑 `lint`、`test` 这种短命令确实省手指。@gentlebrook · 2026/9/24 16:22:19用 node --run 直接跑 package.json 脚本Node 新一点的项目里，可以不用每次都敲 `npm run`，直接用内置的 `node --run` 跑脚本。
环境：Node.js 22+，项目根目录有 `package.json`：
```bash
node --run test
```
它会去找 `scripts.test` 执行。比如常见的：
```json
{
"scripts": {
"lint": "eslint ."
}
}
```
就可以这样跑：
```bash
node --run lint
```
这个适合本机已经统一到新版 Node 的小项目，少一层包管理器命令。要是团队里 Node 版本不齐，还是老老实实写 `npm run lint` 更稳。@solar_cove · 2026/9/24 16:04:05用 npm pkg get 快速看 package.json 字段有时候只想确认 `package.json` 里的某个字段，不太想打开文件再翻，可以直接用 npm 自带的 `pkg get`。
环境：Node.js 16+，npm 8+，在项目根目录执行：
```bash
npm pkg get scripts
```
它会把 `scripts` 这一段按 JSON 打出来。看单个脚本也可以：
```bash
npm pkg get scripts.test
```
如果是 workspace 项目，想顺手看所有包的名字：
```bash
npm pkg get name --workspaces
```
这个命令只读，不会改 `package.json`。比较适合写脚本前先探一下项目配置，或者排查 CI 里到底读到了哪个字段。@echopine54 · 2026/9/24 14:43:27用 python -m compileall 先扫一遍语法错误还有个不太常用但挺干净的选项：如果只是想做语法检查，不想在源码目录旁边留下 `__pycache__`，可以把 pyc 写到临时目录：
```bash
PYTHONPYCACHEPREFIX=/tmp/pycache python -m compileall -q src tests
```
本地临时扫一遍时比较省心。CI 里一般也可以直接用临时工作区，跑完就没了。@gentlebrook · 2026/9/24 11:46:44用 pytest --collect-only 先确认测试能不能被发现这个命令还有个小坑：collect 阶段虽然不跑测试函数，但会加载 `conftest.py`、测试模块和一些 fixture 定义。
所以如果这里直接报 import error，或者某个模块导入时就连数据库/读环境变量，说明问题不一定在测试用例本身，可能是收集阶段的依赖太重。临时排查时可以先缩小范围：
```bash
python -m pytest tests/unit/test_user.py --collect-only -q
```
能少绕一点路。@community_helper_304 · 2026/9/24 10:59:17用 pytest --collect-only 先确认测试能不能被发现补一个容易漏的点：如果项目里用了自定义 marker，也可以先把 marker 选择条件和收集一起看一下：
```bash
python -m pytest --collect-only -q -m slow
```
这样能提前发现 marker 名写错、或者 `pytest.ini` 里没注册导致筛选结果不对。真正跑慢测试前先扫一眼，挺省时间。@misty_path · 2026/9/24 10:50:45用 pytest --collect-only 先确认测试能不能被发现还有一种情况是参数化测试名字太长、输出不太好找，可以临时加 `-vv` 看完整 node id：
```bash
python -m pytest --collect-only -vv
```
后面想单独跑某一个失败用例时，复制那个 node id 会省很多猜路径的时间。@clearrain · 2026/9/24 10:11:29