最近读到一篇深度好文，它提出了一个令人耳目一新的视角：佛学，本质上是一套“高维不确定性处理协议”。 如果将修行看作是一场认知算法的升级，很多玄奥的佛理瞬间变得清晰可见。

一、 世界的底层代码：随机性与熵增

文章给出了一个扎实的基本假设：世界是一个本质随机且不断熵增的复杂系统。

• 苦（Dukkha）： 并非简单的痛苦，而是热力学第二定律下的“系统原生摩擦力”。只要系统在运行，就一定有损耗、有不圆满。
• 无常（Anicca）： 就是数学上的“非平稳随机过程”。世界没有永恒的静态，只有不断的样本取值变化。

如果我们死守着“世界应该是确定的、永恒的”这一过时模型，我们就会在现实的随机海中不断碰撞、报错。承认随机性，是算法优化的第一步。

二、 拆解“我”：是系统涌现，而非独立变量

唯识学中最难理解的“无我”和“第七识”，在系统论下变得异常直观。

• “我”的真相： 科学证明，并没有一个恒定的“指挥官”住在脑子里。所谓的“我”，其实是由基因、环境、记忆等无数相关变量构成的系统。它像旋涡一样，是变量交织产生的“涌现”，而非独立存在的实体。
• 第七识（末那识）： 就像一个被硬编码在系统底层的“自我中心化驱动程序”。它24小时不间断地给全量数据加上“我的”这个标签。这种对局部的过度拟合（Overfitting），导致了我们无法客观建模，产生了巨大的认知噪声。

修行的本质，就是通过“无我”的观察，杀掉这个耗费算力的后台死循环，让系统回归到对因果逻辑的纯净计算。

三、 贝叶斯修行：从“执着”到“动态迭代”

文章将“缘起”精妙地类比为贝叶斯推断（Bayesian Inference）：

后验概率（你的新观点）= 先验概率（旧经验）+ 新证据（当下的缘）

• 执着（偏见）： 就是拒绝根据新证据更新认知。
• 随缘（智慧）： 则是根据当下的“缘”随时修正先验概率。

在这种视角下，“菩萨畏因”有了统计学意义：结果（果）受随机性干扰，是不可控的；但每一次决策的质量（因）是可控的。只要你持续在每一处决策中种下高质量的“因”，时间就会通过大数定律和复利效应，为你结算出必然的“果”。

四、 涅槃：系统的终极收敛

很多人误以为涅槃是某种超自然的神迹，但从控制论角度看，那是“系统的终极收敛”。

当你的认知算法足够强大（内核强大），外界的波动（失业、疾病、毁誉）就不再是让你系统崩溃的攻击，而变成了“如其所是”的风景。

• 凡夫的系统是“发散”的： 一点微小的扰动就能让他痛不欲生。
• 觉醒的系统是“收敛”的： 无论概率之海如何翻滚，他都能通过内部算法的稳定性，抵达那份“如如不动”的平衡点。

五、 结语：照见“如其所是”的秩序

放弃对确定性的病态追求，并不能阻止世界向你投掷随机的“炸弹（痛）”，但它能拆掉你内心那个极易被引爆的火药桶（苦）。

所谓的智慧，是你在觉察了万物的随机底色后，依然能以算法之眼观照缘起，在因果韵律中从容落子。它最终会带你穿透万象幻影，照见那份真相，并让你栖居在一种不被随机性所惊扰的永恒秩序中。

生命不是为了寻找确定性，而是学会在不确定性中，优雅地舞动。

本文观点启发自：https://mp.weixin.qq.com/s/2qB2LTEAU5XXrklrPiZV3Q

这句话听起来无懈可击，符合“知行合一”的古老智慧，也契合库伯（Kolb）的体验学习理论。但在现实中，很多人都在“实践”和“思考”，却依然感到成长停滞，或者陷入精神内耗。

问题出在哪里？问题在于我们对“学习模型”的理解过于简化，以及对“思考”的定义过于宽泛。

经过一番深度拆解，我们发现，真正的深度学习和高阶思维，其实是一个从输入到觉察的精密系统。

一、修正学习模型：为什么必须有“输入”？

如果学习仅仅是“实践 + 思考”，它很容易变成一个封闭的死循环。

• 没有新知的实践，往往只是机械重复（搬砖十年不等于有十年经验）。
• 没有输入的思考，往往是闭门造车，甚至容易演变成一种钻牛角尖。

根据热力学定律，封闭系统必然趋向于“熵增”（混乱）。为了抵抗熵增，我们需要引入外部能量。在学习中，这个能量就是“输入（Input）”。

因此，更准确的学习模型应该是一个螺旋上升的结构：

输入 ➡ 实践 ➡ 思考 ➡ （带着差距）再输入 ➡ 再实践……

1. 输入：引入负熵，打破现有认知的平衡。
2. 实践：验证知识，暴露问题。
3. 思考：提炼规律，发现认知的盲区。
4. 再输入：针对盲区，寻找更高阶的知识。

在这个模型中，输入和输出高频切换，思考则是连接两者的桥梁。

二、警惕“伪思考”：你的大脑只是在产生噪音

既然“思考”是桥梁，为什么很多人的思考无效？

我们需要区分“念头（Thoughts）”和“思维（Thinking）”。

从脑科学角度看，发呆、焦虑、做梦时神经元都在放电，这都算广义的思考。但在学习语境下，这些大多是大脑的噪音。

我们必须剔除以下几种“伪思考”：

• 反刍（Rumination）：反复播放失败的画面或焦虑的情绪。这是死循环，消耗能量却不产出价值。
• 发呆（Zoning Out）：大脑的待机模式。虽然有助于休息，但它不是主动的认知加工。
• 情绪化臆想：没有逻辑支撑的自我攻击或过度自信。

真正的“硬核思考”（System 2 Thinking），必须具备以下特征：

1. 主动性：你是驾驶员，而不是被念头带跑的乘客。
2. 耗能性：真正的思考是累人的，是对信息的刻意加工。
3. 逻辑性：它包含复盘（回溯）、提炼（归纳）、批判（去伪存真）和预测（推演）。

三、思考的引擎：没有提问，就没有深度

如何判断自己是在“胡思乱想”还是在“深度思考”？有一个最简单的试金石：提问。

苏格拉底说：“思考是灵魂与自己的对话。”既然是对话，就必然包含“问”与“答”。

• 低维度的思考往往是陈述句：“我真笨”、“这太难了”、“好无聊”。
• 高维度的思考完全由提问驱动：
  • “这个结论的边界条件是什么？”（批判性思维）
  • “如果环境变了，这个方法还适用吗？”（预测性思维）
  • “除了现有的路径，还有没有别的解法？”（发散性思维）

思考的本质，就是不断提出高质量的问题，并试图求解的过程。 如果你在“思考”时没有产生疑问，那么你的大脑很可能只是在惯性滑行。

四、超越思考：为什么“冥想”是更高维度的智慧？

在讨论思考时，我们不能忽略一个特殊的概念：冥想（或觉察/元认知）。

很多人认为冥想就是“什么都不想”，其实不然。从认知层级来看，冥想是比思考更高维度的“观察”。

如果把大脑比作一台电脑：

• 思考是“应用程序（App）”：你在运行具体的任务，处理具体的内容。
• 冥想是“任务管理器（Task Manager）”：你在监控系统的运行状态。

为什么我们需要这种“上帝视角”？

1. 主客体分离：思考时，你容易与念头融合（觉得“我就是焦虑”）。冥想时，你是观众，看着念头来去（意识到“我有一个焦虑的念头”）。这种抽离感，让你不再被情绪绑架。
2. 打破死循环：当你陷入钻牛角尖的“反刍”状态时，只有更高维度的觉察能发现“系统卡死了”，并强制结束这个进程。
3. 容器与云彩：思考是飘来飘去的云（有黑有白），觉察是天空（容器）。天空接纳云彩，但不等同于云彩。

结语：构建你的认知操作系统

综上所述，一个高手的认知操作系统应该是分层的：

1. 底层（输入与实践）：保持开放，持续行动，获取一手经验。
2. 中层（深度思考）：利用提问作为引擎，对经验进行逻辑加工，去伪存真，归纳演绎。
3. 顶层（觉察/冥想）：保持元认知在线，时刻监控自己的思考状态，确保自己没有陷入情绪的内耗或思维的盲区。

不要满足于大脑里热闹的“动静”，要追求清醒的“洞见”。

在这个信息爆炸的时代，愿你既有锋利的思考之刀，又有握刀的那双觉察之手。

orange-translator 是一个将英文 EPUB 电子书翻译为双语版本的工具，译文紧跟原文段落之后，形成”原文 + 译文”交替排布的阅读体验。表面上看，翻译流程并不复杂：

EPUB 解包 → HTML 解析 → 文本提取 → LLM 批量翻译 → 双语重组 → EPUB 重新打包

真正让我踩坑的，是第三步和第四步之间的那道墙。

核心挑战：内联标签怎么办

EPUB 的 XHTML 里，一段文字往往不是纯文本，而是夹杂着各种内联标签：

<p>
  In <em>The Dhammapada</em>, verse 103 reads:
  <sup><a href="#fn1">1</a></sup>
  "Conquer yourself<br/>rather than the world."
</p>

里面有 <em>（斜体）、<sup>（脚注序号）、<a>（链接）、<br/>（换行）。

如果把整个 inner_html 原样送给 LLM，有几个问题：

1. HTML 标签大量占用 token，增加成本和延迟
2. LLM 不擅长精确复制任意 HTML 结构，容易错位或丢失
3. 翻译后 <em> 里的词可能位置变了，硬保留反而不自然

真正的问题：哪些标签必须保留？哪些可以丢弃？哪些需要特殊处理？

第一个方案：占位符

直觉上，这是个”显然”的解法：把内联标签替换为 LLM 可以透传的占位符，翻译完后再还原。

数学括号 ⟦N⟧

第一版用 Unicode 数学白方括号 ⟦N⟧（U+27E6/U+27E7）作为占位符，透明标签用 ⟦0⟧content⟦/0⟧，不透明标签用 ⟦0⟧。

问题：翻译模型（translategemma:4b）把 ⟦⟧ 翻译成了 《》。

输出变成了这样：

《0》《/0》托《1》奥《/1》曼尼《2》

根本原因：LLM 的训练数据中 ⟦ 极少见，模型会把它当作”奇怪的外语括号”进行翻译，而 《》 是它见过的最相似的括号形式。

教训：占位符不能用模型训练数据中罕见的字符。

XML 风格标签 <gN>

改用 <g0>content</g0> 表示透明标签，<x0/> 表示不透明标签。<g> 和 <x> 在 HTML 中不存在，模型不会把它们当真实 HTML 处理——理论上。

问题：不透明的自闭合 <x0/> 被模型扩展为 <x0>内容</x0>。

模型看到一个孤立的 <x0/> 没有内容，觉得不合理，于是自作主张给它配了内容。

Token 风格 [OT:N]

将不透明标签改为更像”标记/代码”而非”HTML 标签”的格式 [OT:N]。

《》 问题消失了，但新问题出现了：[OT:N] 被模型概率性丢弃。

有时候输出完整，有时候 [OT:0] 凭空消失。丢弃率和 batch 大小、上下文长度、模型状态都有关，不可预测。

占位符方案的根本矛盾

到这里，我意识到占位符方案存在根本性矛盾。

LLM 的翻译本质是：给定源语言文本，生成目标语言的自然表达。它的整个训练目标是生成流畅自然的人类语言。

而占位符要求模型做相反的事：在自然语言输出中，精确地、不遗漏地复制一些非自然语言符号。这与模型的优化目标是冲突的。

小模型尤其无法可靠地完成这个”规则遵从”任务，因为它没有足够的上下文理解能力来始终遵守指令。

重新审视：哪些标签真的需要保留

关键洞察来自对双语 EPUB 使用场景的重新审视：

在双语 EPUB 中，原文就在译文正上方。读者可以直接看到原文的完整格式——斜体、粗体、超链接都在。译文的作用是”帮助理解原文”，而不是”替代原文”。

这意味着：

• <em>、<strong>、<span> 等装饰性格式在译文中可以丢弃，原文已经有了
• <a href> 链接在译文中意义不大
• <br/> 是结构性换行，必须保留（诗歌、台词等场景）
• <sup>/<sub> 通常是脚注序号，丢失了脚注引用就断了
• <a id="N"/> 空锚点是页码标记，完全不可见，直接丢弃即可

一句话：只有影响内容可读性的结构才需要保留，纯装饰性格式可以丢弃。

最小干预方案

基于这个认识，放弃占位符，改为”最小干预预处理”：

def preprocess_for_translation(inner_html: str) -> tuple[str, str]:
    soup = BeautifulSoup(f"<div>{inner_html}</div>", "html.parser")
    div = soup.find("div")

    # 1. 规范化文本节点中的 \n 为空格，避免后续与 <br/> 转换的 \n 混淆
    for text_node in list(div.find_all(string=True)):
        s = str(text_node)
        if "\n" in s:
            text_node.replace_with(NavigableString(s.replace("\n", " ")))

    # 2. <br/> → \n（LLM 能自然保留换行）
    for br in list(div.find_all("br")):
        br.replace_with(NavigableString("\n"))

    # 3. 空锚点直接剥离
    for a in list(div.find_all("a")):
        if not a.get_text(strip=True):
            a.decompose()

    # 4. 装饰性内联标签：保留文字内容，丢弃标签本身
    for tag_name in _STRIP_INLINE:  # em, strong, b, i, span, a, ...
        for tag in list(div.find_all(tag_name)):
            tag.unwrap()

    # 5. sup/sub/img/wbr 保留原始 HTML 不动

    return div.decode_contents(), br_html

还原时，把翻译结果中的 \n 替换回原始的 <br/> 字符串（保留 calibre 生成的 class 属性）。

几个值得注意的细节

为什么先规范化文本节点中的 \n？

XHTML 源文件里有时会有文本节点包含换行符（排版用途）。如果不先规范化，这些 \n 会和 <br/> 转换来的 \n 混淆，还原时会多出多余的 <br/>。

<sup>/<sub> 为什么不用占位符？

实测发现，<sup>1</sup> 这类短标签 LLM 能正确透传——它足够短，不像乱码，模型见过足够多的 HTML 上下文，知道要原样保留。长段落中的复杂嵌套才是问题。

效果对比

速度提升的原因：送给 LLM 的文本更短，prompt token 减少，批次解析失败率降为零。

其他踩坑记录

批量翻译的分段解析

批量翻译时用编号标记让 LLM 分段返回：[1]、[2]……解析时用正则 \[(\d+)\] 切分。

模型偶尔会把多段合并，或者跳过某个编号。解决方案是递归对半重试：10 段失败，拆成两个 5 段重试，直到单段为止。单段永远可以直接返回，无需解析。

ReadTimeout 与流式 API

用 httpx 调 Ollama 时，非流式 API 需要等待完整响应。对于长段落，生成时间可能超过 300 秒，触发 ReadTimeout。

改用流式 API（stream: true），用 aiter_lines() 逐行消费。流式模式下，timeout 针对相邻两个 chunk 之间的等待时间（设为 60 秒），而不是整个响应时间。

续翻支持

翻译 300 章的大部头时中途崩溃，已翻译的部分不能白费。

实现：每章完成后写入 .ot-cache/<md5>.xhtml，同时更新 progress.json。只有全部章节无错误完成时，才清理缓存。有失败章节时，保留缓存，下次运行自动重翻失败的章节。

总结

回头看这次折腾，走弯路的根本原因是：我在用错误的方式提问。

一开始我问的是”如何让 LLM 精确透传 HTML 标签”，这是个错误的问题。LLM 的优化目标是生成流畅的自然语言，不是规则遵从。我想让它做的事，恰好和它的本质相违背。

换一个问题：“哪些格式信息对读者真正重要？” 一旦把问题问对了，答案就清晰了——在双语阅读场景下，原文就在旁边，大量格式信息根本不需要在译文中重复。

让模型做它擅长的事，自己处理规则性的事。这条原则不只适用于 LLM 翻译，适用于所有工具的使用。

引用

• Ollama API 文档

你是否思考过这些问题：

• 为什么常说“Python 中一切皆对象”，连函数和类也是对象？
• 为什么 Python 的变量不需要声明类型？
• type 和 object 到底是什么关系？为什么 type(object) 是 type，而 object 又是 type 的父类？

如果不理解这些，你只是在用 Python 写 C 代码；理解了这些，你才能真正掌握 Python 的“动态之力”。今天，我们就深入 CPython 的源码层面，拆解 Python 的对象模型。

一、 底层解剖：PyObject 是万物之源

Python 的灵活性源于一个核心设计：所有东西在底层都是同一个结构体。

由于 CPython 是用 C 语言写的，当你创建一个整数 a = 10，或者定义一个函数 def func(): pass，在内存中它们并没有本质区别，它们都对应着 C 语言层面的一个结构体——PyObject。

每一个 Python 对象，在内存头部都至少包含两个核心字段：

1. ob_refcnt (引用计数)：
   • 记录有多少个变量指向这个对象。当它变为 0 时，对象会被垃圾回收机制（GC）立即销毁。
2. ob_type (类型指针)：
   • 这是一个指针，指向该对象所属的类对象（Type Object）。
   • 比如整数 10 的 ob_type 指向 int 类。这个指针告诉解释器：“我是一个整数，我支持加减乘除”。

结论： 无论外表多复杂，Python 对象的内核都是一个挂着“引用计数”和“类型标签”的 C 结构体。

二、 核心隐喻：变量是“便利贴”，不是“盒子”

理解对象模型的关键，在于纠正对“变量”的理解。

• 在 C/Java 中： int a = 10; 就像申请了一个名字叫 a 的盒子，把数字 10 放进去。赋值 b = a 是把 10 复制一份放到 b 盒子里。
• 在 Python 中： a = 10 就像在内存里吹起了一个气球（对象 10），然后拿一张写着 a 的便利贴（变量名）贴在气球上。
  • 当你执行 b = a 时，不是复制气球，而是拿一张写着 b 的便利贴，贴在同一个气球上。

这就是为什么 Python 的参数传递全是引用传递（Pass by Assignment）。这也解释了 Python 的“三位一体”特性，任何对象都有：

1. Identity（身份）： 内存地址（id(obj)）。
2. Type（类型）： 它的模具是哪个类（type(obj)）。
3. Value（值）： 气球里的内容。

三、 终极烧脑：type 和 object 的“鸡蛋悖论”

Python 对象模型中最令人困惑，也最精妙的设计，莫过于 type 和 object 的关系。它们构成了对象系统的时空闭环。

3.1 两个主角

• object（万物之祖）： 它是继承链的终点。所有的类（int, str, MyClass）默认都继承自它。它定义了对象最基本的行为（如 __hash__）。
• type（万物之主）： 它是实例化链的源头。也就是所谓的“元类”（Metaclass）。所有的类（包括 object）本质上都是 type 创建出来的实例。

3.2 只有两句话是真的

如果你被绕晕了，只需要记住这两句“绝对真理”：

1. type 是 object 的子类。 （继承维度：type 也是个类，所以它得认 object 做父类）
2. object 是 type 的实例。 （实例化维度：object 这个类对象，是由 type 制造出来的）

print(issubclass(type, object))  # True
print(isinstance(object, type))  # True
print(isinstance(type, type))    # True (自己造自己)

3.3 源码揭秘：C 语言层面的神级操作

你可能会问：这逻辑不通啊？如果是 type 造了 object，那在 type 诞生之前 object 应该不存在；但 type 又继承自 object，说明 type 诞生前 object 必须存在。这不就是死锁了吗？

在 C 语言实现的底层（CPython 源码），开发者通过精妙的指针操作解决了这个“先有鸡还是先有蛋”的问题。这是一个人工打破死循环的过程：

1. 先定义结构体： C 语言代码中，先静态定义了两个核心结构体：
   • PyType_Type（对应 Python 里的 type）
   • PyBaseObject_Type（对应 Python 里的 object）
2. 手动连接（Bootstrap）： 此时它们还只是孤立的 C 结构体，编译器无法处理这种互相依赖。于是，CPython 在初始化时进行了“手动硬连线”：
   • 让 type 成为自己的实例： 把 PyType_Type 的 ob_type 指针指向它自己（&PyType_Type）。
   • 让 type 继承 object： 把 PyType_Type 的 tp_base 指针指向 PyBaseObject_Type。
   • 让 object 成为 type 的实例： 把 PyBaseObject_Type 的 ob_type 指针指向 PyType_Type。

这种“我指你，你指我，我自己指我自己”的操作，在 C 语言层面完美闭合了逻辑环。

3.4 为什么这么设计？

这种看似复杂的环形设计，实际上是为了保证 Python 对象模型的一致性：

• 没有特例： 在 Python 中，一切皆对象。既然 type 和 object 也是对象，它们就必须遵守对象的规则（有类型、有父类）。
• 逻辑闭环： 通过让两者互为依托，Python 关闭了对象系统的顶层逻辑。这确保了无论你在系统中怎么回溯，永远不会遇到一个“不是对象”的东西。

3.5 形象类比

• object 就像是“塑料”这种材质。
• type 就像是“制造模具的机器”。
• 源码层面的操作： 工程师先用手捏了一个“最初的机器”（静态定义的结构体），然后用这台机器造出了所有后续的模具，最后甚至给这台机器贴上了“塑料制造”的标签。

四、 动态机制：类亦是对象与属性查找

基于上述模型，Python 衍生出了极具动态特性的行为。

1. 类也是对象（First-class Citizen）

在 Python 中，class Dog: 这行代码执行完后，内存里真真切切地产生了一个名为 Dog 的对象。 正因为类是对象，所以：

• 你可以把类赋值给变量。
• 你可以把类当参数传给函数。
• 你可以在运行时动态修改类的属性（Monkey Patching）。

2. 属性查找（Attribute Lookup）

当你敲下 obj.x 时，Python 不会像 C++ 那样去偏移内存地址，而是启动了一次哈希查找：

1. 先去 obj.__dict__（实例字典）里找。
2. 没找到？去 obj.__class__.__dict__（类字典）里找。
3. 还没找到？顺着 MRO（方法解析顺序）去父类字典里找。
4. 实在没有？调用 __getattr__ 给你最后一次机会。

这种机制虽然比指针偏移慢，但它带来了无与伦比的灵活性。

五、 总结

Python 的对象模型是一种用空间（内存）和时间（速度）换取极致灵活性的艺术。

• 统一性： 无论是整数、函数还是类，众生平等，皆为对象。
• 元编程： 通过控制 type（元类），你可以控制类的创建过程，这是 Django ORM 等黑魔法的基石。
• 自洽性： 正是 C 语言底层那一次“精妙的指针连接”，让 type 和 object 互为支撑，构建了一个逻辑完美自洽的动态世界。

当你下次写下 class MyClass 时，希望你能意识到：你不仅仅是在写代码，你是在指挥 type 这位造物主，用 object 这种基底材质，为你创造一个新的世界。

这个问题还是在于对其中的某些概念不是很熟悉。下面会分两个部分进行说明。

Py文件的不同

在一个Python项目中，不同的py文件，他们是不同的，我觉得这个概念对于理解Python代码很重要，Java中就没有区别。这个就是Python中的入口文件和模块文件。

主要的区别是__name__和__package__魔术变量的值不同。当py作为入口文件时，__name__的值为__main__，__package__为None。而不是模块文件时，他们都是各自应该有的值。

导致这个问题的原因还是在于脚本语言，当他以文本的方式存在，而不像Java最终会形成jar包，而它所有的文件路径和管理都是在jar包内部。代码以文本的形式保存，代码用目录来组织，他们就需要解决哪里是项目的根目录的问题。

有两个目录是可以确定的：入口文件所在目录和Python程序所在的目录。这也是Python的策略。其他，编程语言也有其他策略，比如Node还可以通过配置文件来实现。

要么显示要么隐式的指定。

理解Python入口文件不能使用相对导入的方式模块也很重要。

包导入

包导入本质上来说是在解决代码复用的问题。如果，没有包导入的功能，我们所有东西都要重新写，那是非常可怕的。而包导入就是在解决这个问题。

所谓的包导入也就是系统默认从几个不同的路径来寻找模块，如果找到就其导入，没找到就报错。默认的模块路径这里就不介绍了，常见的方式就是pip安装包时，它就会安装到默认路径。

这里还有一个很重要的路径就是入口文件所在的目录，也会当做模块导入的默认路径，而且优先级最高。

注意，这是里入口文件所在的目录，而不是你执行代码的目录。这也是符合预期的，也是让我们很方便的导入入口文件所在的目录下包或者模块。

查看包导入路径的方式是

import sys
print(sys.path)

文件路径

Python中文件的读写也是很常见的方式。那么文件的路径如何指定呢？可能不同的编程语言有不同的方式。Python是通过cwd来指定，也就是当前工作目录。

当前工作目录就是执行代码的目录。可以通过如下方式获取cwd路径：

import os
print(os.getcwd())

这里有一点要注意，IDE和命令行的环境不一样，可能导致cwd的目录不同，这也会导致有些代码在IDE中可以执行，而在命令行里无法执行。不要认为Python不可理喻，只是我们缺少一些信息。

__init__.py

__init__.py文件可以理解为就是在为__all__服务，告诉他人当前package中哪些是可以对外使用的。

我们可以理解为import xx导入都是模块。导入包也是导入模块。如果想导入模块中的特定方法、变量就需要使用 from xxx import xx的形式。

Oauth协议为了解决第三方应用授权的问题，如何让第三方应用既能够拿到用户的数据，还能保证用户账号的安全。解决的方式是账号密码只在网站拥有者输入，然后第三方和网站拥有者之间，只是用token进行交流。

Oauth1.0的授权过程比较复杂，还需要对参数排序，还有加密等相对比较繁琐。对于学习来说，了解一下还是有好处，当然，各种语言也有很多库来实现相应的功能。

学习Oauth协议，可能最重要的还是看他们是如何解决第三方授权的问题，以及在Oauth协议升级的过程的演变。

Oauth1.0发布与2009年，可能当时HTTPS使用的并不多，所以在解决其安全性上，是通过对请求参数按照一定规则加密来解决，而在Oauth2.0中直接实用HTTPS就简单很多。

Oauth1.0是为了解决Web应用的授权问题，而并没有在设计上考虑移动端，毕竟07年才发布iPhone第一代。导致移动开发早期大家使用xauth来实现授权登录，它是一种对于Oauth1.0协议的简化，他需要用户提供账号和密码。其实，并不安全。

而在Oauth2.0设计时就充分考虑到移动端的设计。还解决1.0时一个很大的安全问题，授权之后的access_token并没有过期机制。

看Oauth协议的发展，也能体会到技术还是要解决现实的问题。

资料

• https://oauth.net/1/
• https://github.com/oauthlib/oauthlib

Socks5是比较常用的代理协议，它的两个特点让它的使用范围变的很广。

• 支持http、https、ftp等协议
• 支持授权 它是用来转发TCP、UDP，所以也就不关心应用层的到底是何协议。授权解决安全性问题，也就很完美的满足常规代理服务的需求。

通常的用法，在本地运行local服务，在远端运行server服务。本地local服务，即是Socks5的服务端也是Socks5的客户端。作为Socks5的客户端用于接收本地的数据请求。作为Socks5客户端用于与server服务建立连接，传输数据。

资料

• https://en.wikipedia.org/wiki/SOCKS
• https://datatracker.ietf.org/doc/html/rfc1928

在铃木大拙的《通往世界的禅》第一章“关于禅”的文章中有这样一句话，很喜欢，摘录如下。

神僧有言：“我说的话，那是我的，不是你的，也不可能成为你的；一切必须是从你自身中发起和成就。”

我理解这句话神僧应该是用来指导他人修行的，但是对于现代的我们也很有用。

我们被太多的外部评价所裹挟，各种排名、收入高低、领导的期许等等。虽然不能完全避免外部评价，但更加重要的还是要从自身出发，建立自己的内核。

最近，在尝试建立一个新的阅读习惯，就是一本书读两遍。其逻辑就是神僧说的，书中的知识不是你的，只有你通过思考、觉知让他与你产生关系才可能为你所用。而读两遍也是希望自己慢下来，让自己能与它有更深的交流。

这个过程中肯定会有痛苦，就像文章 做主动思考者，痛并快乐着 中说的“哪个真正的思考者是不痛苦的。”

希望自己能成为真正的思考者。

役所广司饰演的男主角平山是一名卫生间清洁工，大概五十岁，独自一人过着平凡而规律的生活。

在片中我最喜欢的画面是平山大叔在推开门上班前，抬头看天的瞬间。面露微笑，平静而感恩。

电影中有一段，平山大叔的小侄女尼可离家出走来找他。尼可跟着平山大叔一起去工作，平山大叔带着手套在擦拭卫生间的镜子，这时尼克还拿出手机在录了一段，这时一位和尼克年龄相仿的女学生需要去卫生间，从她的表情里透着鄙夷。平山大叔赶紧让出卫生间，双手交叉放在身前，很端正的站在门口，这时尼克的神情有一些害羞、茫然，当平山大叔侧过脸，对着尼克露出微笑，尼克感觉突然放下了，对着舅舅也露出微笑。第二天，尼克还尝试帮舅舅在卫生间拖地，虽然她用不好拖把。

每个人都是在用自己的劳动创造价值，本没有贵贱之分。但是，当你在乘坐公交时，身边有一个浑身脏兮兮的建筑工人，大部分人也会想躲开。我们还是会对工作分三六九等，认为打扫卫生间的工作更加低贱一些。倘若我 50 岁时，也只能去做清理卫生间的工作，那时，我会如何看待自己和看待这份工作呢？

至少，平山大叔给了我一个参照。

平山大叔有一位年轻的同事阿隆，工作时会坐在地上一边刷着马桶，一边玩手机。阿隆提到平山大叔为干活方便，会自制一些小工具。这应该是导演刻意的设计，但是从中也能看出两种完全不同的生活态度，我们需要有理想，也要活在当下。做好你能做好的事情。

什么样的日子是完美的呢？我不知道。但是我知道，这样的日子里我会面带微笑。

原理

一点开 Let’s Encrypt 还是有点懵的，按照在其他平台申请 SSL 证书的逻辑，它尽然不用注册，那怎么管理证书呢？随着不断的了解，对它也越来越佩服。

Let’s Encrypt 贡献两个主要的东西

• ACME protocol
• boulder

ACME 全称 Automatic Certificate Management Environment。它提供一套自动证书管理的规范，这套规范中包含客户端与服务端。而 boulder 就是 Let’s Encrypt 提供的一套开源的证书颁发软件。ACME 客户端官方没提供，只要支持 ACME 协议都可以实现。目前，官方推荐的客户端是 certbot。

证书颁发机构只需要确认你拥有该域名的所有权，就可以帮你生成证书（需要注意 Let’s Encrypt 并不支持 OV 和 EV 证书）。

在服务器上运行 ACME 客户端，已自动化的方法确认用户对于域名的所有权，然后向 Let’s Encrypt 服务端申请证书，通过后，既可以得到所需要的 SSL 证书。

Let’s Encrypt 生成的免费证书有效期为 90 天，但是它也支持自动续签。

使用

以下操作，基于 CentOS7.8 + Nginx 服务器。

安装 certbot

它是一款在 Linux 上使用的现代包管理工具。

# Centos7 中安装 snapd
sudo yum install epel-release
sudo yum install snapd
sudo systemctl enable --now snapd.socket
sudo ln -s /var/lib/snapd/snap /snap

# 查看 snapd 服务状态
sudo systemctl status snapd

# 安装 certbot
snap install --classic certbot

可以参考官方文档：https://certbot.eff.org/instructions?ws=nginx&os=snap

申请证书

certbot 有一些傻瓜式的方式可以直接一键生成证书并安装。但是这并不是我需要的，我只希望他帮我生成证书，然后自己在 Nginx 中配置。

sudo certbot certonly --webroot -w /path/to/webroot -d example.com -d www.example.com

这条指令的作用是以 http 的方式验证域名并单独生成证书。-w 指定域名所在的根目录，-d 指定需要验证的域名。以上命令成功后，它会在 /etc/letsencrypt/live/example.com/ 目录中生成证书。

部署证书

部署证书的操作，另行搜索即可。

自动续签

在证书还有 30 天过期时，重新验证域名的所有权。验证成功重新颁发证书，并重启 Nginx 服务。 certbot 已经将这些功能实现，只需要进行少量配置即可。

# 验证是否能够续签
sudo certbot renew --dry-run

验证续签功能通过，说明当前环境没问题。

通过snap安装certbot时，会自动在systemctl中安装续签定时调度。可以通过如下指令查看。

systemctl list-timers

看到如下配置，说明定时调度配置是成功的。

# systemctl list-timers
NEXT                         LEFT       LAST                         PASSED       UNIT                         ACTIVATES
Mon 2025-11-03 22:55:00 CST  8h left    Mon 2025-11-03 06:52:12 CST  7h ago       snap.certbot.renew.timer     snap.certbot.renew.service

后续，我们只需要在/etc/letsencrypt/renewal-hooks/deploy在目录中添加部署脚本reload-nginx.sh，即可实现自动续签和自动重启Nginx服务。

#!/bin/bash

# 日志文件
LOG_FILE="/var/log/certbot-hook.log"
DATE=$(date '+%Y-%m-%d %H:%M:%S')

# 记录开始
echo "========================================" >> "$LOG_FILE"
echo "[$DATE] Hook 脚本开始执行" >> "$LOG_FILE"

# 测试 Nginx 配置
echo "[$DATE] 测试 Nginx 配置..." >> "$LOG_FILE"
if nginx -t >> "$LOG_FILE" 2>&1; then
    echo "[$DATE] Nginx 配置测试通过" >> "$LOG_FILE"

    # 重载 Nginx
    echo "[$DATE] 开始重载 Nginx..." >> "$LOG_FILE"
    if systemctl reload nginx >> "$LOG_FILE" 2>&1; then
        echo "[$DATE] ✅ Nginx 重载成功" >> "$LOG_FILE"
        exit 0
    else
        echo "[$DATE] ❌ Nginx 重载失败" >> "$LOG_FILE"
        exit 1
    fi
else
    echo "[$DATE] ❌ Nginx 配置测试失败，跳过重载" >> "$LOG_FILE"
    exit 1
fi

其他

# 强制更新证书
sudo certbot certonly --webroot -w /path/to/webroot --force-renewal --deploy-hook "nginx -s reload" -d example.com -d www.example.com

注意

如果你修改过 webroot 路径，记得要将 /etc/letsencrypt/renewal/ 目录中对应的配置中相关路径修改为修改过后的路径。

引用

• https://letsencrypt.org/
• https://datatracker.ietf.org/doc/html/rfc8555
• https://github.com/letsencrypt/boulder
• https://certbot.eff.org/