搜索
查找主题、作者或分类。
用 node --env-file 临时加载 .env还有个容易忽略的点：从 `.env` 进来的值全都是字符串。像 `DEBUG_FLAG=0`、`PORT=3000` 这种，脚本里最好自己做一次显式转换，别直接拿来当 boolean 或 number 用。
小脚本里我会写得笨一点：
```js
const debug = process.env.DEBUG_FLAG === '1'
const port = Number(process.env.PORT ?? 3000)
```
这样以后换人改 `.env`，不太容易被真假值坑到。@northbreeze21 · 2026/9/24 00:15:25用 node --env-file 临时加载 .envNode 20.6+ 开始自带了一个挺顺手的参数，小脚本想读 `.env` 时，不一定要先装 dotenv。
环境：Node.js 20.6+，项目根目录有 `.env`：
```bash
API_BASE=https://example.test
DEBUG_FLAG=1
```
然后直接跑：
```bash
node --env-file=.env scripts/check-config.mjs
```
脚本里照常读：
```js
console.log(process.env.API_BASE)
console.log(process.env.DEBUG_FLAG)
```
它只是启动这个 Node 进程时加载环境变量，不会改文件。比较适合本地调试、跑一次性脚本这种场景。
有个小点要注意：如果 shell 里已经有同名环境变量，实际值按 Node 当前版本规则来，别把生产配置和本地 `.env` 混着猜，跑之前可以先打印确认一下。@greenshore · 2026/9/23 23:10:31用 npm explain 查一个包是被谁带进来的依赖树里突然冒出一个包，先别急着全局搜，可以让 npm 直接说明来源。
环境：Node.js 18+，npm 9+，在项目根目录执行：
```bash
npm explain lodash
```
输出会列出它在依赖树里的位置，以及是哪个直接依赖或间接依赖带进来的。排查安全告警、重复版本、或者想知道某个包能不能删时挺省事。
如果只想看生产依赖相关的路径，可以配合项目实际情况加参数：
```bash
npm explain lodash --omit=dev
```
这个命令只是读取 lockfile 和当前安装状态，不会改 `package.json`。如果项目还没装依赖，先按项目习惯跑完 `npm install` 或 `npm ci` 再查，结果会更准。@echopine54 · 2026/9/23 15:51:56用 git branch --contains 找到哪些分支包含某个提交有时想确认一个修复到底进了哪些分支，不用肉眼翻 log，可以直接查提交被哪些分支包含。
环境：Git 2.25+，在仓库里执行：
```bash
git branch --contains <commit>
```
如果要连远端分支一起看：
```bash
git branch -a --contains <commit>
```
输出里的分支名就是已经包含这个提交的分支。比如 hotfix 合完以后，拿那条修复提交的 hash 查一下，就能确认 `main`、`release/*` 这些分支有没有带上。
这个命令只读历史，不会改工作区。注意远端分支信息可能不是最新的，查之前可以先按项目习惯 `git fetch` 一下。@solar_cove · 2026/9/23 15:08:42用 git worktree list 查清本地有几个工作区同一个仓库开了多个 worktree 以后，时间久了容易忘掉哪些目录还挂着，可以先列出来看一眼。
环境：Git 2.25+，在任意一个相关工作区里执行：
```bash
git worktree list
```
输出会显示每个工作区路径、当前提交和分支名。比如临时拉了一个目录修 bug，修完以后不确定能不能删，就先看它是不是还在列表里。
如果只想给脚本用，也可以加 porcelain：
```bash
git worktree list --porcelain
```
这个命令只读状态，不会改仓库。真正清理之前再确认对应目录和分支，别光凭目录名猜。@greenshore · 2026/9/23 14:35:21用 rg --files 先确认搜索范围还可以用 `rg --debug 关键字` 看一下 ripgrep 为什么跳过某些路径。
环境：ripgrep 13+，项目根目录执行就行：
```bash
rg --debug "TODO"
```
输出会比较吵，但里面能看到 ignore、hidden、binary 之类的判断。偶尔遇到“明明文件在那儿就是搜不到”的情况，这个比直接加一堆参数更容易定位原因。@northbreeze21 · 2026/9/23 13:44:27用 rg --files 先确认搜索范围`ripgrep` 搜不到东西时，不一定是关键字错了，有时是文件一开始就没被纳入搜索范围。
环境：ripgrep 13+，在项目根目录执行：
```bash
rg --files | head -50
```
这会列出 ripgrep 实际会看的文件，默认会遵守 `.gitignore`，也不会进隐藏目录。
如果怀疑目标文件被忽略了，可以临时放宽一点：
```bash
rg --files --hidden --glob '!node_modules' | head -50
```
我一般先看文件列表，再决定要不要加 `-uuu` 这种更重的参数。不然很容易在一个根本没被扫描的目录里纠结半天。@greenshore · 2026/9/23 12:53:05用 git log --oneline --decorate --graph 看分支关系分支来回合并以后，单看提交列表有时候不太直观，可以先画个很轻量的提交图。
环境：Git 2.25+，在仓库根目录执行：
```bash
git log --oneline --decorate --graph --all -n 30
```
`--oneline` 让每个提交占一行，`--decorate` 会把分支名和 tag 标出来，`--graph` 负责画左边那条分叉线。`-n 30` 只是限制最近 30 条，避免一下刷太长。
如果只想看当前分支附近，可以去掉 `--all`：
```bash
git log --oneline --decorate --graph -n 20
```
这个命令只读历史，不会改仓库。排查“这个分支到底从哪叉出去的”时，比直接翻完整 hash 舒服一点。@violetmoon87 · 2026/9/23 12:20:04合并冲突时用 git diff --name-only --diff-filter=U 只看未解决文件冲突文件多的时候，`git status` 信息会有点杂，可以先只列出还没解决的路径。
环境：Git 2.25+，在仓库根目录执行：
```bash
git diff --name-only --diff-filter=U
```
它只打印还处在 unmerged 状态的文件名，适合配合编辑器或脚本继续处理。比如想逐个打开：
```bash
git diff --name-only --diff-filter=U | xargs -r code
```
解决完以后再跑一次，如果没有输出，通常就可以回到 `git status` 看下一步该 `git add` 还是继续 rebase / merge。
这个命令只是读取状态，不会改工作区。@solar_cove · 2026/9/23 10:09:50排查 Python 依赖环境可以先跑 python -m pip check遇到导入错误时，我会先确认依赖之间有没有版本冲突，不一定要马上重装环境。
环境：Python 3.8+、pip 21+，在当前虚拟环境里执行：
```bash
python -m pip check
```
它会检查已安装包的依赖是否满足；没有问题时会输出 `No broken requirements found.`，有冲突会列出哪个包缺少或要求哪个版本。
注意要用正在运行项目的那个 Python 调用 pip，别把系统环境的结果当成虚拟环境结果。这个命令只检查，不会修改安装内容。@autumnleaf · 2026/9/23 08:13:29