Worker 不是一台服务器，也不是一个需要自己常驻运行的进程。它更像是部署在 Cloudflare 网络中的一段事件处理代码：请求来了，Cloudflare 调用它；它处理完请求，返回结果。
最常见的事件就是 HTTP 请求。一个最小的 Worker 大致是这样：
export default {
async fetch(request: Request): Promise<Response> {
return new Response("Hello Worker!");
},
};
这里没有 app.listen()，也没有端口号。我们只需要实现 fetch，请求到来时 Cloudflare 会把请求交给它，并把返回的 Response 发回给用户。
Cloudflare 提供了 Wrangler 作为本地开发和部署工具。创建项目、在本地运行、部署到线上，通常只需要下面几步：
npm create cloudflare@latest -- hello-worker
cd hello-worker
npm run dev
npm run dev 会在本地启动开发环境。修改 src/index.ts 后，访问本地地址就可以看到结果。确认没有问题后，再执行：
npm run deploy
Wrangler 会将项目中实际需要的代码和配置部署到 Cloudflare。部署完成后，Worker 可以绑定到 workers.dev 地址、自定义域名，或者站点的某个路由。
用户访问 Worker 的地址时，请求会先到达 Cloudflare 的网络。Cloudflare 根据域名和路由找到对应的 Worker，再调用它的 fetch 方法。
在 fetch 中，可以直接读取 URL、请求头和请求体，也可以用 fetch 请求其他服务。例如可以在这里做鉴权、改写请求、读取数据，或者把请求转发到已有的后端服务。最后返回一个 Response，这一次请求就结束了。
所以 Worker 很适合放在请求入口处。它可以是一个简单的 API，也可以做页面渲染、接口聚合、鉴权、缓存控制，或者在请求到源站之前先处理一遍。
除了 HTTP 请求，Worker 也可以处理定时任务、队列消息等事件。不过理解 HTTP 请求的处理方式后，其他事件的思路也是一样的：Cloudflare 在事件发生时调用代码，而不是让我们维护一个一直等待事件的服务进程。
Serverless 并不是没有服务器。服务器依然存在，只是由 Cloudflare 负责运行、扩容、维护和调度。
传统部署时，我们通常需要关心一台机器或一个容器：进程是否启动、监听哪个端口、流量增加时开多少实例、实例异常后如何重启。Worker 把这些事情收进了平台内部。开发者只关注收到什么事件，以及应该返回什么结果。
这也是 Serverless 最重要的变化：从“维护一个长期运行的应用”，变成“描述一次事件该如何处理”。
Cloudflare Workers 使用 V8 isolate 运行代码。它比启动一个完整的 Node.js 进程轻得多，因此可以更快地创建和复用运行环境。但这不表示某个 Worker 会一直留在内存中。下一次请求可能复用原来的 isolate，也可能被分配到新的 isolate。
因此不能把 Worker 的内存当成数据库。例如下面这样的全局变量，不能用于保存用户数据或业务状态：
let count = 0;
它可能因为运行环境被复用而暂时保留，也可能在下一次请求时消失。全局变量可以用作临时优化，但不能作为正确性所依赖的数据来源。
这就是 Serverless 开发中很重要的一点：把计算和状态分开。
Worker 负责处理请求和执行业务逻辑；需要持久化的数据，则放到专门的存储中。比如 D1 适合关系型数据，KV 适合配置和读取频繁的键值数据，R2 用来放文件和对象。如果业务需要对某个对象进行有状态的协调，还可以使用 Durable Objects。
这样做一开始会觉得比把数据放在内存里麻烦，但它让服务可以随时扩容、迁移和恢复，而不依赖某个特定进程一直活着。
理解 Worker 的关键不在于它用了什么打包工具，而在于转换这个思路：它不是一台缩小版的服务器，而是一段由平台按事件调用的代码。把状态交给合适的存储，把请求处理交给 Worker，才是使用 Serverless 的正确方式。
@asynccontextmanager
async def lifespan(app: FastAPI):
# 1. 启动前：连接资源
await redis_service.connect()
print(">>> 服务已启动")
yield # <--- 关键看这里
# 2. 关闭后：清理资源
print(">>> 服务正在关闭")
await redis_service.disconnect()
这段代码看着简单，但却引出了 Python 中最迷人、也是最重要的机制之一：生成器（Generator）。
为什么一个 yield 就能让函数“暂停”？它会不会阻塞线程？Java 和 JavaScript 也有类似机制吗？本文将从应用层深入到 CPython 虚拟机底层，带你彻底理解 yield 背后的黑魔法。
普通函数是“一锤子买卖”，调用 return 后，函数结束，所有局部变量销毁。
而生成器函数（带 yield 的函数）是“可以暂停的函数”。
形象的理解：
在 FastAPI 的 lifespan 中，yield 起到的作用不是生成数据，而是控制流的移交：
yield，函数暂停（挂起），控制权交给 FastAPI 主程序去处理 HTTP 请求。yield 后面继续运行，执行清理工作。yield 会挂起线程吗？这是很多开发者的误区。答案是：绝对不会。
yield 挂起的是“函数”，而不是“线程”。
我们可以通过打印线程 ID 来验证：
import threading
def my_generator():
print(f"生成器内 线程ID: {threading.get_ident()}")
yield 1
print(f"生成器内 线程ID: {threading.get_ident()}")
def main():
print(f"主程序 线程ID: {threading.get_ident()}")
gen = my_generator()
next(gen)
print("--- 主程序继续干活 ---")
next(gen)
# 输出结果显示，所有 ID 都是一模一样的！
发生了什么？ 这就像一场接力赛。
yield 把棒子（CPU 控制权）交还给调用者。next() 把棒子又交回给生成器。相比之下，time.sleep() 才是真正的线程挂起，它会让操作系统把当前线程踢出 CPU，导致 CPU 闲置或调度其他线程。
为什么 C/C++ 的函数一旦 return 栈内存就没了，而 Python 可以“复活”？
这得益于 Python 的解释器架构。
在 C 语言层面，函数调用栈是操作系统分配的一块连续内存，函数返回即释放，不可逆。
而在 Python 中，栈帧（Stack Frame）是一个在“堆内存”上分配的对象（PyFrameObject）。
既然是堆上的对象，它的生命周期就不受系统栈的限制，而是由 Python 解释器控制。
当你调用生成器时：
f_lasti，记录代码跑到哪一行），并将这个栈帧对象从执行链上摘下来，保存在生成器对象里。栈帧没有被销毁，局部变量依然活着。yield 的下一行继续执行。这完全是用户态（User Mode）的行为，操作系统对此一无所知。
yield 到 async/awaityield 的功能经历了三个阶段的演变，最终成就了今天的 Python 异步生态：
send()，允许外部向生成器发送数据。生成器变成了协程（Coroutine），可以实现协作式多任务。async/await。虽然语法变了，但底层依然是基于“函数暂停/恢复”的机制。FastAPI之所以快，就是因为它利用这种机制（基于 asyncio），在单线程内实现了高并发。当一个请求在等待数据库（IO）时，Python 利用 await（底层类似 yield）挂起当前任务，立刻切换去处理另一个请求，压榨 CPU 的每一分性能。
Python 这种“解释器保留堆栈帧”的做法并非业界唯一标准。
Java 语言层面没有像 Python 这样通用的 yield 生成器。
Stream.iterate，基于函数式编程接口。yield，JVM 会自动检测阻塞并挂起虚拟线程。JS 的实现与 Python 类似但不同：
function* / yield 和 async/await。switch-case 跳转执行位置。await 本质上是将后续代码封装成回调放入微任务队列。当你再次在 FastAPI 中写下 yield，或者在脚本中写下 async def 时，请记住：
你正在使用 Python 最强大的特性之一：用户态非抢占式多任务处理。
它利用堆内存上的栈帧对象，骗过了操作系统，实现了代码执行流的自由穿梭。这不仅让代码更优雅，更是 Python 在高并发领域的一把利剑。
]]>最近读到一篇深度好文，它提出了一个令人耳目一新的视角：佛学，本质上是一套“高维不确定性处理协议”。 如果将修行看作是一场认知算法的升级，很多玄奥的佛理瞬间变得清晰可见。
文章给出了一个扎实的基本假设：世界是一个本质随机且不断熵增的复杂系统。
如果我们死守着“世界应该是确定的、永恒的”这一过时模型，我们就会在现实的随机海中不断碰撞、报错。承认随机性，是算法优化的第一步。
唯识学中最难理解的“无我”和“第七识”，在系统论下变得异常直观。
修行的本质，就是通过“无我”的观察，杀掉这个耗费算力的后台死循环，让系统回归到对因果逻辑的纯净计算。
文章将“缘起”精妙地类比为贝叶斯推断（Bayesian Inference）：
后验概率（你的新观点）= 先验概率（旧经验）+ 新证据（当下的缘）
在这种视角下，“菩萨畏因”有了统计学意义：结果（果）受随机性干扰，是不可控的；但每一次决策的质量（因）是可控的。只要你持续在每一处决策中种下高质量的“因”，时间就会通过大数定律和复利效应，为你结算出必然的“果”。
很多人误以为涅槃是某种超自然的神迹，但从控制论角度看，那是“系统的终极收敛”。
当你的认知算法足够强大（内核强大），外界的波动（失业、疾病、毁誉）就不再是让你系统崩溃的攻击，而变成了“如其所是”的风景。
放弃对确定性的病态追求，并不能阻止世界向你投掷随机的“炸弹（痛）”，但它能拆掉你内心那个极易被引爆的火药桶（苦）。
所谓的智慧，是你在觉察了万物的随机底色后，依然能以算法之眼观照缘起，在因果韵律中从容落子。它最终会带你穿透万象幻影，照见那份真相，并让你栖居在一种不被随机性所惊扰的永恒秩序中。
生命不是为了寻找确定性，而是学会在不确定性中，优雅地舞动。
本文观点启发自：https://mp.weixin.qq.com/s/2qB2LTEAU5XXrklrPiZV3Q
]]>这句话听起来无懈可击，符合“知行合一”的古老智慧，也契合库伯（Kolb）的体验学习理论。但在现实中，很多人都在“实践”和“思考”，却依然感到成长停滞，或者陷入精神内耗。
问题出在哪里？问题在于我们对“学习模型”的理解过于简化，以及对“思考”的定义过于宽泛。
经过一番深度拆解，我们发现，真正的深度学习和高阶思维，其实是一个从输入到觉察的精密系统。
如果学习仅仅是“实践 + 思考”，它很容易变成一个封闭的死循环。
根据热力学定律，封闭系统必然趋向于“熵增”（混乱）。为了抵抗熵增，我们需要引入外部能量。在学习中，这个能量就是“输入（Input）”。
因此，更准确的学习模型应该是一个螺旋上升的结构：
输入 ➡ 实践 ➡ 思考 ➡ （带着差距）再输入 ➡ 再实践……
在这个模型中，输入和输出高频切换，思考则是连接两者的桥梁。
既然“思考”是桥梁，为什么很多人的思考无效？
我们需要区分“念头（Thoughts）”和“思维（Thinking）”。
从脑科学角度看，发呆、焦虑、做梦时神经元都在放电，这都算广义的思考。但在学习语境下，这些大多是大脑的噪音。
我们必须剔除以下几种“伪思考”：
真正的“硬核思考”（System 2 Thinking），必须具备以下特征：
如何判断自己是在“胡思乱想”还是在“深度思考”？有一个最简单的试金石：提问。
苏格拉底说：“思考是灵魂与自己的对话。”既然是对话，就必然包含“问”与“答”。
思考的本质，就是不断提出高质量的问题，并试图求解的过程。 如果你在“思考”时没有产生疑问，那么你的大脑很可能只是在惯性滑行。
在讨论思考时，我们不能忽略一个特殊的概念：冥想（或觉察/元认知）。
很多人认为冥想就是“什么都不想”，其实不然。从认知层级来看，冥想是比思考更高维度的“观察”。
如果把大脑比作一台电脑：
为什么我们需要这种“上帝视角”？
综上所述，一个高手的认知操作系统应该是分层的：
不要满足于大脑里热闹的“动静”，要追求清醒的“洞见”。
在这个信息爆炸的时代，愿你既有锋利的思考之刀，又有握刀的那双觉察之手。
]]>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，有几个问题：
<em> 里的词可能位置变了，硬保留反而不自然真正的问题：哪些标签必须保留？哪些可以丢弃？哪些需要特殊处理？
直觉上，这是个”显然”的解法：把内联标签替换为 LLM 可以透传的占位符，翻译完后再还原。
⟦N⟧第一版用 Unicode 数学白方括号 ⟦N⟧（U+27E6/U+27E7）作为占位符，透明标签用 ⟦0⟧content⟦/0⟧，不透明标签用 ⟦0⟧。
问题：翻译模型（translategemma:4b）把 ⟦⟧ 翻译成了 《》。
输出变成了这样：
《0》《/0》托《1》奥《/1》曼尼《2》
根本原因：LLM 的训练数据中 ⟦ 极少见，模型会把它当作”奇怪的外语括号”进行翻译，而 《》 是它见过的最相似的括号形式。
教训：占位符不能用模型训练数据中罕见的字符。
<gN>改用 <g0>content</g0> 表示透明标签，<x0/> 表示不透明标签。<g> 和 <x> 在 HTML 中不存在，模型不会把它们当真实 HTML 处理——理论上。
问题：不透明的自闭合 <x0/> 被模型扩展为 <x0>内容</x0>。
模型看到一个孤立的 <x0/> 没有内容，觉得不合理，于是自作主张给它配了内容。
[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 上下文，知道要原样保留。长段落中的复杂嵌套才是问题。
| 方案 | 速度 | 缺陷 |
|---|---|---|
⟦N⟧ 占位符 |
基准 | ⟦⟧ → 《》 转译 |
<gN>/<xN/> |
-5% | <xN/> 被扩展为含内容标签 |
<gN>/[OT:N] |
-10% | [OT:N] 概率性丢弃 |
| 最小干预（最终） | +22% | 无已知缺陷 |
速度提升的原因：送给 LLM 的文本更短，prompt token 减少，批次解析失败率降为零。
批量翻译时用编号标记让 LLM 分段返回：[1]、[2]……解析时用正则 \[(\d+)\] 切分。
模型偶尔会把多段合并，或者跳过某个编号。解决方案是递归对半重试：10 段失败，拆成两个 5 段重试，直到单段为止。单段永远可以直接返回，无需解析。
用 httpx 调 Ollama 时，非流式 API 需要等待完整响应。对于长段落，生成时间可能超过 300 秒，触发 ReadTimeout。
改用流式 API（stream: true），用 aiter_lines() 逐行消费。流式模式下，timeout 针对相邻两个 chunk 之间的等待时间（设为 60 秒），而不是整个响应时间。
翻译 300 章的大部头时中途崩溃，已翻译的部分不能白费。
实现：每章完成后写入 .ot-cache/<md5>.xhtml，同时更新 progress.json。只有全部章节无错误完成时，才清理缓存。有失败章节时，保留缓存，下次运行自动重翻失败的章节。
回头看这次折腾，走弯路的根本原因是：我在用错误的方式提问。
一开始我问的是”如何让 LLM 精确透传 HTML 标签”，这是个错误的问题。LLM 的优化目标是生成流畅的自然语言，不是规则遵从。我想让它做的事，恰好和它的本质相违背。
换一个问题：“哪些格式信息对读者真正重要？” 一旦把问题问对了，答案就清晰了——在双语阅读场景下，原文就在旁边，大量格式信息根本不需要在译文中重复。
让模型做它擅长的事，自己处理规则性的事。这条原则不只适用于 LLM 翻译，适用于所有工具的使用。
你是否思考过这些问题：
type 和 object 到底是什么关系？为什么 type(object) 是 type，而 object 又是 type 的父类？如果不理解这些，你只是在用 Python 写 C 代码；理解了这些，你才能真正掌握 Python 的“动态之力”。今天，我们就深入 CPython 的源码层面，拆解 Python 的对象模型。
Python 的灵活性源于一个核心设计：所有东西在底层都是同一个结构体。
由于 CPython 是用 C 语言写的，当你创建一个整数 a = 10，或者定义一个函数 def func(): pass，在内存中它们并没有本质区别，它们都对应着 C 语言层面的一个结构体——PyObject。
每一个 Python 对象，在内存头部都至少包含两个核心字段：
ob_refcnt (引用计数)：
ob_type (类型指针)：
10 的 ob_type 指向 int 类。这个指针告诉解释器：“我是一个整数，我支持加减乘除”。结论： 无论外表多复杂，Python 对象的内核都是一个挂着“引用计数”和“类型标签”的 C 结构体。
理解对象模型的关键，在于纠正对“变量”的理解。
int a = 10; 就像申请了一个名字叫 a 的盒子，把数字 10 放进去。赋值 b = a 是把 10 复制一份放到 b 盒子里。a = 10 就像在内存里吹起了一个气球（对象 10），然后拿一张写着 a 的便利贴（变量名）贴在气球上。
b = a 时，不是复制气球，而是拿一张写着 b 的便利贴，贴在同一个气球上。这就是为什么 Python 的参数传递全是引用传递（Pass by Assignment）。这也解释了 Python 的“三位一体”特性，任何对象都有：
id(obj)）。type(obj)）。Python 对象模型中最令人困惑，也最精妙的设计，莫过于 type 和 object 的关系。它们构成了对象系统的时空闭环。
object（万物之祖）： 它是继承链的终点。所有的类（int, str, MyClass）默认都继承自它。它定义了对象最基本的行为（如 __hash__）。type（万物之主）： 它是实例化链的源头。也就是所谓的“元类”（Metaclass）。所有的类（包括 object）本质上都是 type 创建出来的实例。如果你被绕晕了，只需要记住这两句“绝对真理”：
type 是 object 的子类。 （继承维度：type 也是个类，所以它得认 object 做父类）object 是 type 的实例。 （实例化维度：object 这个类对象，是由 type 制造出来的）print(issubclass(type, object)) # True
print(isinstance(object, type)) # True
print(isinstance(type, type)) # True (自己造自己)
你可能会问：这逻辑不通啊？如果是 type 造了 object，那在 type 诞生之前 object 应该不存在；但 type 又继承自 object，说明 type 诞生前 object 必须存在。这不就是死锁了吗？
在 C 语言实现的底层（CPython 源码），开发者通过精妙的指针操作解决了这个“先有鸡还是先有蛋”的问题。这是一个人工打破死循环的过程：
PyType_Type（对应 Python 里的 type）PyBaseObject_Type（对应 Python 里的 object）PyType_Type 的 ob_type 指针指向它自己（&PyType_Type）。PyType_Type 的 tp_base 指针指向 PyBaseObject_Type。PyBaseObject_Type 的 ob_type 指针指向 PyType_Type。这种“我指你，你指我，我自己指我自己”的操作，在 C 语言层面完美闭合了逻辑环。
这种看似复杂的环形设计，实际上是为了保证 Python 对象模型的一致性：
type 和 object 也是对象，它们就必须遵守对象的规则（有类型、有父类）。object 就像是“塑料”这种材质。type 就像是“制造模具的机器”。基于上述模型，Python 衍生出了极具动态特性的行为。
在 Python 中，class Dog: 这行代码执行完后，内存里真真切切地产生了一个名为 Dog 的对象。
正因为类是对象，所以：
当你敲下 obj.x 时，Python 不会像 C++ 那样去偏移内存地址，而是启动了一次哈希查找：
obj.__dict__（实例字典）里找。obj.__class__.__dict__（类字典）里找。__getattr__ 给你最后一次机会。这种机制虽然比指针偏移慢，但它带来了无与伦比的灵活性。
Python 的对象模型是一种用空间（内存）和时间（速度）换取极致灵活性的艺术。
type（元类），你可以控制类的创建过程，这是 Django ORM 等黑魔法的基石。type 和 object 互为支撑，构建了一个逻辑完美自洽的动态世界。当你下次写下 class MyClass 时，希望你能意识到：你不仅仅是在写代码，你是在指挥 type 这位造物主，用 object 这种基底材质，为你创造一个新的世界。
这个问题还是在于对其中的某些概念不是很熟悉。下面会分两个部分进行说明。
在一个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协议的发展，也能体会到技术还是要解决现实的问题。
资料
]]>Socks5是比较常用的代理协议，它的两个特点让它的使用范围变的很广。
通常的用法，在本地运行local服务，在远端运行server服务。本地local服务，即是Socks5的服务端也是Socks5的客户端。作为Socks5的客户端用于接收本地的数据请求。作为Socks5客户端用于与server服务建立连接，传输数据。
在铃木大拙的《通往世界的禅》第一章“关于禅”的文章中有这样一句话，很喜欢，摘录如下。
神僧有言：“我说的话，那是我的，不是你的，也不可能成为你的；一切必须是从你自身中发起和成就。”
我理解这句话神僧应该是用来指导他人修行的，但是对于现代的我们也很有用。
我们被太多的外部评价所裹挟，各种排名、收入高低、领导的期许等等。虽然不能完全避免外部评价，但更加重要的还是要从自身出发，建立自己的内核。
最近，在尝试建立一个新的阅读习惯，就是一本书读两遍。其逻辑就是神僧说的，书中的知识不是你的，只有你通过思考、觉知让他与你产生关系才可能为你所用。而读两遍也是希望自己慢下来，让自己能与它有更深的交流。
这个过程中肯定会有痛苦，就像文章 做主动思考者，痛并快乐着 中说的“哪个真正的思考者是不痛苦的。”
希望自己能成为真正的思考者。
]]>