第 1 天：诊断、学习方法与环境

参考解答与执行追踪：
1. 预测输出：
Case 1: [1, 2, 3, 4]
Case 2: [1, 2, 3, 4, 5]
Case 3: True False
2. 根因解析：
- b = a 让 b 与 a 引用同一个列表对象（id(a) == id(b) 成立即同一对象）。b.append(4) 修改该列表内容，因此 a 的内容也变为 [1, 2, 3, 4]。
- a + [5] 会调用列表的 __add__，创建一个新的列表对象赋值给 c，因此 a is c 为 False，a 自身保持不变。
3. 极简复现示例 (MRE):

x = []
   y = x
   y.append(1)
   assert x == [1] and x is y  # 原地修改共享引用

参考执行记录（新 shell 中的 bash/zsh；路径为示例）：

$ python3 --version
Python 3.14.8
$ python3 -c "import sys; print(sys.executable); print(sys.prefix); ..."
/usr/bin/python3         # 之前状态：基础解释器，未激活 venv
/usr
/usr
True                     # 新 shell 中 prefix == base_prefix
$ mkdir venv-sandbox && cd venv-sandbox && printf 'marker\n' > marker.txt && python3 -m venv .venv
$ . .venv/bin/activate
$ echo "$VIRTUAL_ENV"
.../venv-sandbox/.venv
$ python -c "import sys; print(sys.executable); print(sys.prefix); ..."
.../venv-sandbox/.venv/bin/python   # 调用路径（可能是符号链接）——以 prefix 为准
.../venv-sandbox/.venv
/usr
False                    # prefix != base_prefix → 解释器已隔离
$ python -c "print(open('marker.txt').read().strip())"
marker                   # venv 的 Python 仍可读取 .venv 之外的文件 → 非文件系统沙箱
$ python -m pip --version
pip 26.2.1 from .../venv-sandbox/.venv/lib/python3.14/site-packages/pip (python 3.14)
$ deactivate
$ python3 -c "import sys; print(sys.executable); print(sys.prefix); ..."
/usr/bin/python3         # 回到记录的之前状态
/usr
/usr
True

不变量成立的原因：sys.prefix 表示运行中解释器所属的环境，sys.base_prefix 始终表示基础安装；在 venv 内二者不同，这就是可检验的隔离特征。sys.executable 报告的是调用解释器的路径，可能是 .venv 内的符号链接，因此应以 prefix 值而非解析出的可执行路径为准。python -m pip 通过当前解释器解析 pip。$VIRTUAL_ENV 与 PATH 的变化是激活机制，deactivate 将其还原，结尾探针必须与记录的之前状态一致。

边界：该隔离只覆盖解释器与包——venv 解释器自己读取了 .venv 之外的 marker.txt 并输出 marker，说明它不是文件系统沙箱；.venv 始终绑定创建它的解释器。

参考执行记录（节选；哈希与 main/master 名因环境而异）：

$ git status
... Untracked files: notes.txt            # 新文件，尚未暂存
$ git add notes.txt && git diff --cached
+first line                              # 可见已暂存的新增
$ git commit -m "Add notes file"
[main (root-commit) 8bddb5d] Add notes file
$ printf 'second line\n' >> notes.txt && git status --porcelain
 M notes.txt                             # 已修改，尚未暂存
$ git diff
+second line                             # 可见未暂存差异
$ git add notes.txt && git commit -m "Append a second line to notes"
[main a0d6969] Append a second line to notes
$ git log --oneline
a0d6969 Append a second line to notes    # 新提交在前
8bddb5d Add notes file

提交是已暂存树的快照，加上零个或多个父提交 ID 与元数据——最初的根提交没有父提交；git log 用来验证该快照确实存在。git status 区分未跟踪（??）、未暂存修改（ M）与已暂存；git diff 显示未暂存差异，git diff --cached 显示已暂存内容。作者信息用不带 --global 的 git config 设置，只存在于此一次性仓库的 .git/config 中。git-sandbox/ 之外未被改动，也不需要任何破坏性命令。

示例日志（仅为示范，不是照抄模板）：

第一步——独立回忆（合上所有参考资料）：
- b = a 让 b 指向同一个列表，所以 b.append 会改变 a。a + [5] 为 c 新建列表。
- venv 提供隔离。我写了“它会沙箱化整个程序”——错误。
- git add 给文件做快照，commit 把它保存。
第二步——对照检查与纠正（现在打开参考答案）：
误解：虚拟环境能阻止程序读我的文件。
今天实际观察到的证据：在激活的 .venv 中，venv 解释器自己的 python 读取 marker.txt 仍打印出
'marker'——该文件在 .venv 之外、一次性沙箱之内。venv 探针改变的是
sys.executable/sys.prefix 和 pip 使用的 site-packages，文件访问并未被阻止。
这是解释器/包隔离，不是文件系统沙箱。
没想起的条目：为什么推荐 python -m pip 而不是裸 pip（如实记录而非猜测）。
第三步——新的独立检查（再次合上参考资料）：
不用笔记的新例子：d = [9]; e = d; e.append(0) — 无辅助预测：因为 e 指向同一个列表对象，
d == [9, 0]。随后实际运行并观察到 [9, 0]——这是用实际输出核对的结果，不是凭记忆的断言。
第四步——补救步骤：
明天 09:00、Day 02 开始前：凭记忆重新推导 b = a 与 a + [5]；
若仍不确定，重跑 sys.prefix != sys.base_prefix 探针。

对照量规自查：第一步用自己的措辞复述了两个概念；第二步把一个误解与今天实际观察到的命令输出配对记录（若未发现误解，则改为记录“未发现误解”并附一个用证据否定的常见误解）；第三步记录了一次新的独立检查及其结果；第四步安排了带日期的补救步骤。仅声称“全部正确”无法满足量规的证据项。