Python文件处理
用 pathlib 整理文件路径
处理文件时，路径往往比读写本身更容易出错。直接拼接字符串，需要自己照顾分隔符，也容易让“相对于哪里”变得含糊。Python 标准库中的 pathlib 可以让这些关系更清楚。
先确定路径的起点
如果配置文件与脚本放在一起，就以脚本所在目录为起点，而不是依赖启动命令时的工作目录。下面的例子适用于普通 Python 脚本：
from pathlib import Path
base_dir = Path(__file__).resolve().parent
config_path = base_dir / "config.json"
content = config_path.read_text(encoding="utf-8")
/ 在这里用于组合路径，read_text 则把读取方式和编码放在同一处。路径从哪里来、文件如何读取，都能顺着代码看出来。
让缺失的文件明确报错
必需的配置文件不存在时，读取操作会抛出异常。不要随手返回空字符串来掩盖它：缺少配置和配置为空是两件事。先明确文件是否必需，再决定怎样处理错误。
记住路径的起点，比记住分隔符更重要。
Git日常工作流
提交之前，先读一遍差异
一次提交最好只讲清楚一件事。修改完成后，先不要急着提交，花一点时间检查工作区和暂存区，常常能发现遗留的调试输出、无关格式变化，或者遗漏的文件。
分清“改了什么”和“准备提交什么”
# 查看文件状态
git status --short
# 查看尚未暂存的修改
git diff
# 只暂存本次相关文件
git add index.html style.css
# 检查真正要提交的内容
git diff --cached
git diff 默认展示工作区相对暂存区的变化；git diff --cached 展示暂存区相对当前提交的变化。两者回答的问题不同，提交前尤其要看后者。
把提交说明写成一句具体的话
“调整页面”很难说明改动的目的，“修复手机端目录文字溢出”则能帮助后来的自己快速定位。检查差异时，也可以反问一句：这些修改能否用同一句话解释？如果不能，考虑拆开提交。
检查暂存区，就是给即将留下的记录做一次校对。
问题排查开发习惯
让一次排查留下线索
遇到错误时，最容易做的事是马上改代码。更有效的第一步，往往是把现象描述清楚：什么输入、什么环境、经过哪些操作，出现了什么结果。
先写下一个最小复现
从原来的流程中逐步移除无关步骤，每移除一步都重新验证。保留仍然能触发问题的最小输入和操作序列，让猜测变成可以重复观察的事实。
现象：从其他目录启动脚本时，读取配置失败。
预期：无论从哪里启动，都读取脚本旁的配置。
复现：切换到父目录，再运行同一个脚本。
线索：相对路径以当前工作目录为起点。
验证：分别从脚本目录和父目录启动，检查结果。
一次只验证一个假设
如果同时修改路径、编码和异常处理，即使问题消失了，也很难知道是哪一处起了作用。把假设写下来，只改与它有关的部分，再用原来的复现步骤验证。
最后记录原因、修复位置和验证方法。说明里不必留下全部尝试过程，保留能让下一个人理解结论的证据即可。
好的排查记录，让同一个问题少占用下一次时间。