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/

参与InLong的起因是赋闲在家，虽然平时也会关注技术相关的发展，但是也担心久不写代码会手生。而参与开源项目就成为我的一个选项，在前司主要是负责大数据接入侧工作，也是出于对腾讯公司的喜爱就将目标锁定在Apache InLong上。

虽然，对于自身的技术水品并不担心，但是多少还是有一些恐惧在里面，这种恐惧可能来自于Apache的名头或者完美主义的想象。所以，在一开始我选择先在inlong-website项目中提交代码，它是InLong的官方文档项目。在阅读文档的过程中，自然的会发现一些问题（没有问题是不可能的）。参考其他已经合并的issue，自己也开始写文档，提交修改。

我们出生在一个好的时代，虽然我的英语很烂，但是翻译工具已经能满足我基本的需求。如果有这方面担心的朋友完全不用担心，你要相信维护项目的人一定能看懂你写的可能有错误的英语。

连续在inlong-website中提交3个PR并成功合并后，我也基本掌握项目的贡献流程，更为重要的打破了心里的恐惧（面对它，才能解决它），后面在主项目中提交PR也就水到渠成。

我有一个习惯，在了解新东西时会先将所有公开的信息浏览一遍，包含文档、项目、公众号、公开视频等，这个过程也是在建立整体的认知，比如公众号中一些介绍InLong demo运行的文章，就比官方文档更加详细和个性化。

接下来，我将精力花费在搭建开发环境和阅读代码上。这里有两个小建议：其一，不要放过任何一个在玩项目中出现的你认为有问题的地方；其二，明确自己感兴趣的模块，这能让自己的精力更加集中。InLong项目给我的第一印象是项目结构很好，CI/CD构建方面有很多是公司项目里可以借鉴的。只要愿意去深挖总能发现一些有意思和值得学习的点。这也是参与开源项目对个人的价值所在吧。

我已经记不得是如何与InLong项目PMC docker建立联系的。在与他的沟通中表达自己参与InLong项目的意愿，他给我了我很多的鼓励，也会将一些issue分给我，让我能更快的融入开源团队。

参与开发的过程中，让我更加确定理解业务和沟通可能比编码更重要。项目的开发者分布在天南地北，没法像在公司里一样，拉个会就能将问题对齐。而且，作为新人你对于项目整体架构和设计掌握的不够全面，那么在涉及重要功能或者全局性的修改时更要谨慎，先将方案沟通清楚再写代码会事半功倍。

当然，每个程序员都是各自的审美与坚持。难免，在一些功能实现细节和风格上会产生争执。这种时候需要一些妥协。我相信这些都能解决，毕竟大家参与到InLong项目的建设都是希望它更好。

这段时间断断续续的提交8个PR，目前正在开发sort中基于Flink1.15的kafka-connector。对我来说心态的变化是最大的，在使用InLong遇到问题不再是想着将其抛出去，而是去研究它为什么会如此，我能怎么解决它。感谢一路上帮助过我的docker、wake、van、healchow、goson等等。

最后，如果你看到这篇文章，也愿意参与到开源项目的建设中，那么参与InLong会是你非常好的选择，因为这是一个有爱的团队。

Apache InLong项目：https://github.com/apache/inlong

docker安装

参考华为云开源镜像中Docker-CE镜像的配置。

sudo yum install -y yum-utils device-mapper-persistent-data lvm2

wget -O /etc/yum.repos.d/docker-ce.repo https://repo.huaweicloud.com/docker-ce/linux/centos/docker-ce.repo

sudo sed -i 's+download.docker.com+repo.huaweicloud.com/docker-ce+' /etc/yum.repos.d/docker-ce.repo

sudo yum makecache fast
sudo yum install -y docker-ce

sudo systemctl start docker

PS：注意以上命令在CentOS8中有问题，只推荐在CentOS7中使用。

docker-compse安装

直接从docker-compse在github的项目中下载指定平台和架构的二进制文件。 比如linux平台 x86_64平台。

curl -L https://github.com/docker/compose/releases/download/v2.19.0/docker-compose-linux-x86_64 -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

华为云docker镜像加速

在华为云中支持docker镜像加速。 登录华为云账号后找到SWR服务后，如下图找到镜像加速器按钮。

弹出如下配置：

配置完成后，重启docker

sudo systemctl restart docker

资料

• https://docs.docker.com/engine/install/centos/
• https://mirrors.tuna.tsinghua.edu.cn/help/docker-ce/