游壳说 – 托克的诺亚方舟

用上这4个原则，为AI编程提效

Wed, 27 May 2026 00:00:00 +0000

Andrej Karpathy 最近写了一份 CLAUDE.md 示例，只有 4 条规则。

有人拿去测了：编码准确率从 65% 涨到 94%。

不是模型变强了，是约束条件做对了。

Karpathy 是谁不用多说。Tesla AI 前总监，OpenAI 创始成员。他识别的不是"怎么让 AI 写更好代码"，而是 AI 编码助手最常见的 4 种失败模式，然后给每条配了一条行为契约。

这 4 条后来被扩展成 12 条，在 GitHub 上拿了 82,000 星。但核心没变：不是让 AI “更聪明”，而是让它别在同样的地方摔倒。

你的 AI 为什么总在重复犯错

打开你的 CLAUDE.md，大概率能看到这种话：

写高质量代码。
仔细思考。
保持简洁。

然后呢？

AI 点头说"好的"，然后继续犯同样的错。

需求没对清楚就开始改。修一个小 bug 顺手把旁边一片代码也动了。假设项目里有某种约定，然后写出一套"看起来合理"、但和当前代码库完全不搭的实现。

最麻烦的不是它犯错，而是它犯错的过程很有迷惑性。先偏一点，再修一点，再偏一点。你看着它忙来忙去，甚至会觉得它快好了。最后才发现，它不是在靠近答案，是在被污染的上下文里继续打补丁。

从一个真实案例说起

我手头有个老 Go 项目，依赖 GOPATH 管理，但本地装的是默认用 go module 管理依赖的高版本 Go。

每次让 agent 跑测试，它都直接执行 go test ./...，报错后开始自我修正：先试 go mod init。不对。再试 GO111MODULE=off。还是不对。再试手动设置 GOPATH 指向某个它猜的目录。

来回自纠了四五轮才搞定。

实际上，直接把"本项目使用 GOPATH 模式管理依赖"写进 CLAUDE.md，一行就能解决。

但 agent 不知道这条信息存在。所以它每次都要重复试错。

我当时想解决的不是"怎么让 AI 更聪明"。

是更朴素的问题：能不能有一个地方，把这些重复出现的问题写下来，让 agent 每次进项目之前先看到？

记忆系统无法解决团队协作问题

我一开始用过 IDE 自带的记忆系统，把项目规约、常见坑和个人偏好塞进去。有用，但不够稳。

一个问题是记忆太个人化。个人项目里还好，多人项目里就会变成隐形分叉：同一个 repo，不同开发者的 agent 带着不同记忆工作。有人知道这个项目不能引入某个库，有人不知道；有人知道某个老模块不能随便重构，有人不知道。代码库没有分叉，上下文先分叉了。

另一个问题是加载不确定。你以为它记住了，但你不知道它在当前任务里到底有没有看到。简单任务可能没事，复杂任务一长，关键规则就可能被挤出上下文或者选择性遗忘。

后来我才觉得，项目里真正关键的规则不应该只放在某个人的私人记忆里。它应该进仓库，被版本管理，跟代码一起被所有人看到。CLAUDE.md 对我来说就是这个定义：不是更长的系统提示词，而是项目仓库级别的协作约定。

不再滥用 `/init`

刚开始用 Claude Code 时，我也用过 /init。它扫一遍项目，生成一份 CLAUDE.md，看着是很省事。但我很快发现一个问题：它太喜欢把代码细节写成长期上下文。

目录结构、模块说明、当前命令、实现细节，这些东西短期看有帮助，长期很容易变成旧地图。代码一改，CLAUDE.md 里的描述就开始腐化。更糟的是，agent 可能会相信这份旧描述，而不是重新读代码。

我现在更倾向于让代码细节留在代码里。AI 编码智能体本来就擅长现场搜索：读调用方、查导出、看测试、顺着工具函数摸上下文。根 CLAUDE.md 不该抢这个工作，它只需要告诉 agent 哪些事每次都要知道，哪些边界不能踩。

后来我试过把 CLAUDE.md 清空，从头手写。只保留两类内容：给 AI 的通用编码规则，以及这个项目专属的规则。效果比预期好了很多。agent 还是会犯错，但更少乱发散，也更少擅自改无关代码，同时生成的代码风格品味和质量也变高了。它像是终于知道这个项目不是一个随便发挥的空白练习场。

Karpathy 的 4 条铁律

Karpathy 的 4 条编码铁律非常短。短到你会怀疑"就这些？"

1. Think before coding. State your assumptions. Surface tradeoffs.
   Ask before guessing. Push back when a simpler approach exists.

2. Simplicity first. Minimum code that solves the problem. No
   speculative features. No abstractions for single-use code.

3. Surgical changes. Touch only what is asked. Do not "improve"
   adjacent code, comments, or formatting. Match existing style.

4. Goal-driven execution. Define success criteria. Loop until
   verified. Do not narrate steps; tell me what success looks like.

翻译成中文，就是四个问题：

Rule 1 - 编码前先思考，别直接开写

AI 最常见的失误：面对有歧义的需求默不作声，直接动手写。结果发现理解有误，只能推倒重来。

对应的契约：在处理非琐碎任务前，先阐明你的前提假设。遇到不确定的细节要主动发问。如果察觉到存在更简单的方案，要敢于提出异议。

Rule 2 - 简单优先，别过度工程

AI 为了"专业"会加抽象、加配置、加工具函数。看起来厉害，但后面的 agent 会继续沿着这个复杂结构扩建。

对应的契约：写解决当前问题所需的最少代码。不要实现用户没要求的功能。单次使用的逻辑不要提前抽象。

Rule 3 - 手术刀式修改，别顺手重构

老代码库里很多难看的代码不是没人看见，而是不敢轻易动。它可能背着历史兼容、客户定制、线上事故后的补丁。

AI 没有这种历史负担。看到重复就想消除，看到不一致就想统一。在修 bug 的任务里，这是风险。

对应的契约：只改被要求修改的部分。不要"顺手改进"相邻代码、注释或格式。匹配现有风格。

Rule 4 - 目标驱动，别自说自话

AI 最怕的不是"我不知道"，而是"我觉得我知道"。自信满满地给出一个错误方案，比承认不确定要危险得多。

对应的契约：定义成功标准。循环验证直到达成。不要 narrate 步骤，告诉我成功长什么样。

这 4 条不是"我希望你怎样"。而是"在这个场景下，你必须怎样做"。

差别就在这里。

为什么这 4 条比 20 条更有效

Karpathy 的 4 条后来被扩展成 12 条。但有个反直觉的发现：规则超过 14 条后，AI 的合规率反而从 76% 掉到 52%。

为什么？

规则一多，每条规则的权重就变轻了。模型会"平均"掉所有规则，最后谁都不记得。

一个贴合项目的 6 条规则，通常比复制来的 20 条更有用。

所以我现在的做法：先放 Karpathy 的 4 条作为基线。然后根据项目真实失败模式，一条一条加。每加一条都要能对应一个具体场景：“上周 AI 在这个地方摔过跤”。

加的时候问自己：这条规则如果不存在，AI 会在哪个具体场景下犯错？

答不上来，就别加。

从 4 条到 12 条：什么时候扩展

Karpathy 的 4 条处理的是"写代码这一刻"。但在实际 agentic workflow 中，失败模式远不止这 4 种。

后来扩展的 8 条，补的是这些缺口：

Token 预算不是建议：长调试会话里，AI 会重复尝试、上下文污染，最后把问题越修越偏。
每个重要步骤后 checkpoint：多步骤任务中，错误会在后续步骤上继续叠加。
测试验证意图，不只验证行为：AI 会写"会通过但不验证业务意图"的浅测试，制造虚假信心。
暴露冲突，不要折中平均：遇到两套冲突代码风格时，AI 可能"取平均"写出第三种怪物。
匹配代码库约定，即使你不同意：AI 可能引入自认为更好的新范式，导致同一代码库双模式并存。
只把模型用于判断题：让 LLM 处理重试、路由、状态码等确定性逻辑，是浪费且危险的。

这些不是否定 Karpathy 的 4 条，而是说：先守住基线，再按需扩展。

我的建议是：新项目先用 4 条跑两周。每次 AI 犯错，判断是不是这 4 条没覆盖到。如果是，再加一条。不是，就修现有规则的表述。

项目规则不要写成百科

通用规则只是底座。而真正让 agent 在一个项目里跑顺的，还是项目自己的规则。

我现在会优先写这些东西：

项目用什么技术栈和依赖管理工具
常用的命令清单
应该怎么本地验证和测试
有哪些外部依赖和中间件

验证闭环尤其值得写清楚。比如：

修改后优先运行 pnpm typecheck。
涉及 API 行为时运行 pnpm test:api。
涉及 UI 时启动本地 dev server，并用浏览器确认关键页面可打开。
如果无法运行验证命令，必须立即退出并说明原因。

还有一类项目规则，我不会一开始就靠想象补全，而是边用边加。每次 agent 跑得不顺，任务结束前可以让它复盘一句：

仔细回顾一下刚刚犯过的一些错，并将经验教训用简明的语言总结成不超过 2 句话的项目开发原则。

这句话你可以直接专门写个 skill，每次任务跑完之后用下这个技能，然后由人再判断这句话值不值得写进 CLAUDE.md。注意只有从真实失败里长出来的项目规则，才更可能在下一次派上用场。真实工程里面从来没有银弹。

根 CLAUDE.md 更像入职说明

日常工作中，我会把 AI 编码智能体当成一个刚接手项目的实习生。它很聪明，读得快，也愿意干活，但它不知道项目为什么长成这样，不知道哪里不能碰，也不知道团队过去在哪些地方踩过坑。

给新同事做 onboarding 的时候，你不会把公司历史和每个模块的实现细节全塞给他。你会先说清楚几件事：项目在做什么，用什么技术栈，怎么测试验证改动，哪些目录高风险，遇到不确定该去哪里查。

CLAUDE.md 也差不多。根文件放每次都要知道的最小知识集，不放会频繁过时的细节。代码细节让 agent 现场搜；可选上下文放在 docs/ 或 Skills 里，让模型认为有相关性时再渐进式加载。

最终一个足够直接拿来用的结构可以很短：

# CLAUDE.md

## 项目
本仓库是一个 [项目类型]。
核心目标：[系统用来做什么]。
主要用户：[内部运维 / 客户 / 开发者]。

## 行为规则
- 编码前先思考：非琐碎任务开始前，先复述需求、成功标准和关键假设。
- 简单优先：写解决当前问题所需的最少代码；避免猜测性抽象。
- 手术刀式修改：只修改任务必需的文件；未经确认不要重构相邻代码。
- 先读后写：添加新代码前，先检查已有导出、调用方、测试和本地约定。
- 大声失败：如果跳过了检查或存在不确定性，要明确说明。

## 项目规则
- 使用 [包管理器] 管理依赖和脚本命令。
- 未经确认不要引入 [库 / 模式 / 服务]。
- 遵循 [关键目录] 中的已有模式。
- 修改 [XX模块] 前，先阅读 [docs/路径.md]。

## 验证
- TypeScript 改动后运行 [类型检查命令]。
- 逻辑改动后运行 [测试命令]。
- 如果任何命令无法运行，说明跳过了什么以及原因。

## 其他
- 架构细节放在 docs/architecture.md。
- API 契约放在 docs/api.md。
- 历史决策放在 docs/decisions.md。
- 只在相关时按需加载，不要把它们的内容抄进本文件。

这份模板不是让你照抄，而是给一个边界感：根文件只负责稳定事实、行为边界、项目红线、验证闭环和上下文路由。它越像百科全书，越容易变成噪音。

什么时候更新

CLAUDE.md 不是那种一次写完就不修改的文件。我更愿意把它当成测试一样维护：agent 犯了一个你不想再看到的错，就问它是不是可复发的失败模式；如果是，再看一条短规则能不能提前拦住。

如果某条信息每次任务都需要知道，放进根 CLAUDE.md。如果只在某类任务里需要，放进对应文档或 skill。如果必须强制执行，别只靠文字，交给 hooks、测试或 CI。

这也是我不喜欢把 CLAUDE.md 写得太长的原因。规则太多之后，每条规则都变轻了。一个贴合项目的 6 条规则，通常比复制来的 20 条规则更有用。

立刻开始

打开你的项目根目录。

创建一个 CLAUDE.md。

把 Karpathy 的 4 条贴进去，然后补充最基本的项目说明和测试验证规则：

# CLAUDE.md

## 通用编码规则

1. Think before coding. State your assumptions. Surface tradeoffs.
   Ask before guessing. Push back when a simpler approach exists.

2. Simplicity first. Minimum code that solves the problem. No
   speculative features. No abstractions for single-use code.

3. Surgical changes. Touch only what is asked. Do not "improve"
   adjacent code, comments, or formatting. Match existing style.

4. Goal-driven execution. Define success criteria. Loop until
   verified. Do not narrate steps; tell me what success looks like.

## 项目专有规则

技术栈：
依赖管理：
测试：
lint：

补充规则：
- XXX
- XXX

通过 ln -s CLAUDE.md AGENTS.md 链接兼容类似 Qoder 这样的 IDE。

然后跑两周。

每次 AI 犯错，记下来。判断是这 4 条没覆盖到，还是它根本没遵守。

如果是没覆盖到，加一条。如果是没遵守，修表述。

两周后，你会有一份真正属于你的 CLAUDE.md：不是从别人那里复制来的，是从你的真实失败模式里长出来的。

写 CLAUDE.md 不是为了让 AI “记住我说过什么”。

它不会让 agent 不犯错。但会让错误少一点、偏航短一点、返工可控一点。

Karpathy 的 4 条原则不是终点，是起点。

真正改变的其实不是 AI 的行为，而是你把那些本来只存在于人脑里的隐形上下文，变成了项目的一部分。

致精神股东们的信2026

Sat, 14 Feb 2026 16:30:00 +0800

前言

2025 年是变幻莫测的一年，随着 AI 大模型能力日益强大，变革发生的速率也随之变快。每几个月都会有新的能力或者应用爆发出来，与此同时又有新的领域不断被 AI 深度渗透，而所有人都必须接受现实的这些变化。

然而越是变化，就越需要透过表象看清其本质，就如同汪洋大海里的定海神针，以不变应万变。因此，从新年开始，我希望将过去一年里得到的经验结论都以写作的形式总结沉淀下来。然后在新的一年里去不断践行，被验证正确的结论方法，继续坚持，如果被验证错误的，也能及时修正。

真正有价值的事情，值得长期坚持，通过年终总结来复盘算是其中之一。在这方面，伯克希尔每年的股东信已经做到了极致。25 年末，当巴菲特写完最后一封致股东的信后，这个世界又少了一位无私奉献智慧的长者，而我也深受这种利他主义的正面影响。每年信中都会有新的投资观点出现，但不变的是真诚的分享与反思。对我而言写作是思想的磨刀石，而分享是连接志同道合人士（精神股东）的途径，也是个人影响力的放大器，所以作为受益者，我希望将这种形式继续发扬光大。就当是交个朋友，如对各位精神股东有所帮助，本人不胜荣幸。

现在开始，聊聊我所熟悉又陌生的互联网世界吧。

互联网世界的变革

现在互联网世界每天依旧在产生巨量的数据，然而数据生产者，生产速度以及所有权已经悄然变化，AI 已在生产力中发挥关键协同作用，甚至已经可以脱离人的提示进入自我反思自迭代的飞轮阶段。当我们在享受着 AI 带来的巨大提效的同时，人类正在逐步给 AI 授权更大的权限。数据以超乎想象的速度开始急剧膨胀，而人有限的注意力也在超负荷过载。

因此我开始思考：在这个信息过载的时代，人与 AI 共存的生产关系及消费链路中，人的作用什么？或者说当经验技能不再重要时，作为人还能有哪些可以提升的方向？才能尽可能参与这波时代浪潮，让 AI 朝我们想要的方向发挥杠杆效应。

过去一年中发生的事情，不仅仅是生产力变革，已有的消费模式也随之改变。因此我将分别阐述我最近得到的一些结论。

AI智能体生产循环机制

按照生产端分析，从第一性原理出发，AI 智能体的循环机制可以拆解为：

上下文（数据）+ 模型推理 + 工具调用

在上下文部分发挥作用，我们可以

定义好提供给 AI 的问题以及需求（问题定义以及工程分解）
主动给 AI 提供或生产优质的未被预训练的上下文（独特或即时内容优先）
从模型大量预训练数据中通过提示词提取出优质内容作为上下文

而在模型推理上，我们可以

从事 AI 模型或者智能体方面相关的工作，涉及模型算法或底层基建
通过投资相关上下游的产业链，获取推理需求增长的红利
利用推理举一反三的能力进行逆向和模仿
在各个垂直领域尽量使用最佳模型追求极致生产力

工具是人已有经验+重复工作流的沉淀
在工具上，我们可以

利用 AI 的推理能力将原先重复繁琐的流程自动化
将领域经验总结输出固化成 SOP 文档
将有价值的工具打包产品化，规模化

对于循环机制：

严格的定义验收计划和标准
过程中保持领域内的判断力
发现跑偏了人为介入，及时纠错
总结经验，形成长期可复用记忆

消费侧的变革

在消费侧，由 AI 生成的内容已在各大社交媒体中爆炸式增长，此时此刻 Seedance 2 视频模型火爆全球。文字，图片，音乐以及视频生成的内容质量已经远超想象。当这个世界已经不谈论这个内容是否是 AI 生成时，就标志着 AI 驱动生产内容的工作以及消费模式已经成熟，我相信在未来，我们会越来越难看到未经过大模型制作的原创内容。随着时间的推移，最终大部分可供消费的内容都会由 AI 驱动生产，包括客户端的分发与推荐。

同时，生产出的消费内容也面临着知识产权上的巨大争议。在绕开数据所有者授权的情况下，模型公司将抓取到的原始数据，直接预训练至模型当作为先验知识，然后在消费侧大肆传播其衍生品获取额外收入，而数据版权的所有者无法获取分成。这种模式不可持续，也不利于平台创作者生产更优质的内容，但好像短时间也没什么好办法，还是交给内容平台去解决吧。

文字的力量

深入理解大模型 Transformer 架构的最小单位是 token 有着极大的帮助，因为它能够帮助我们找到，在依旧能发挥人主观能动性的未来，潜在杠杆率最大的媒介。对大模型而言所有的输入输出皆为 token，但高质量的输出依赖于高质量的输入，如果按照输入输出种类进行划分可以得到这样的表格：

输入	输出
文本	文本
文本	图片
文本	视频
图片+文本	图片
视频+文本	视频

聪明的股东们或许已经发现了端倪，文本媒介的输入是一切“魔法”能够运作的基础，并且在其中起到了决定性的作用，撬动了最多的杠杆，文字的力量不言而喻。随着模型能力的增强，写作技能本身可能会成为未来最重要的基础技能，其它一切目标都可以由文字去定义，最终由 AI 去产出并完成。

又因为输入文字能够生成文字，所以任何人都能够快速制造各种内容。大量 AI 生成的快消内容会像病毒一样在互联网传播泛滥，直至淹没一切。有人说原创已死，因为 AI 模仿的速度实在太快了，以至于全网都难以找到真正的原作者。但正因如此，有人味的内容在未来有极大可能会成为稀缺资源。

所谓人味，是创作者独特生命体验的沉淀——那些亲身经历过的高低起伏、踩过的坑、得到过的教训，这一切的综合构成了任何AI都无法复制的精神资产。因此像人一样独立思考依旧重要，拟合的是人类的学习曲线和路径，而非冷冰冰的多维数学多项式。

当个人文学的力量从未像现在这样如此强大时，如果还不做点什么的话确实可惜。所以沉寂已久的我再度出手玩自媒体，在26年第一个月我决定立马行动，将从前的学习笔记重新进行整理，并在 AI 的协助下，三周内快速地将上百篇的技术笔记用 AI 自动分类、打标、摘要、翻译，全部公开发表在我 vibe coding 搭建的双语独立博客中。后续我会发表更多独立思考的作品，公众号也会同步更新，总之先上了这车再说。

展望未来

未来，我们身边的“创作者”会比以往任何时候都要多，AI 让每个人都能轻易拿起作家之笔、画家之笔和导演的取景器。老实说，我无法预测这个人人皆可创作的世界最终会走向何方。但我相信，参与其中，亲手制造一些有价值的内容，至少不是一笔亏本的买卖。至于这些投入最终能否转化为真正的价值？让时间去检验吧。我深知自己无法做到完美，也看不清路通向何方，但“贵在坚持”，没准能做大做强。

在新年来临之际，我效仿我最敬仰的偶像巴菲特写下这段文字，分享我对 AI 互联网世界的一点浅见。感谢所有看到这里的朋友们，愿我们在新的一年里，都能成为更好的自己。

最后祝大家新年快乐！

全文完

Docker 容器与容器云读书笔记

Mon, 26 Jan 2026 00:00:00 +0000

Iaas 基础设施即服务 Paas 平台即服务 Saas 软件即服务

容器云以容器为资源分割和调度的基本单位，专注资源共享和隔离，容器的编排和部署

每个docker命令都会发送给Docker daemon 进行处理这个守护进程默认绑定一个unix socket

Dockerfile -> build -> image 镜像 run 变成容器 Push 发布镜像 tag 进行版本控制容器有生命周期每新建一个新的容器，docker 会分配一个新的ID作为唯一标识符 Docker commit 可以将一个容器固化成一个新的镜像，可以让在容器中安装的工具不丢失，但官方还是建议使用Dockerfile build 来创建镜像

节点互联的时候会通过 hosts 文件 自动维护联接的 ip 映射，类似DNS，使得容器的ip 可以任意改变，因此两两连接的节点的启动顺序至关重要，需要暴露在公网的节点最后启动配置文件等需要编辑的文件使用数据卷的方式与宿主机共享填写ip 配置的时候填写 link 参数的连接名，连接的时候容器会自动去 hosts 查找实际的 ip 地址

Namespace

PID 解决进程冲突
Network 解决网络配置冲突
Mount 文件挂载
User 解决用户冲突

同一个 namespace 下的进程可以感知到彼此的变化，而对外界一无所知

使用 clone 来实现创建不同的 namespace 查看 namespace 的方式：/proc/pid/ns 目录下的文件，如果两个进程指向的namespace 相同，那么它们就在同一个 namespace 下

setns() 可以用于加入一个已经存在的 namespace，进程从原先的 namespace 加入某个已经存在的 namespace，后使用 clone() 创建子进程继续执行命令。常用于 docker exec 在已有 namespace 中执行 shell 命令

UTC namespace

提供主机名和域名的隔离，使得隔离进程可以在网络上被视为一个独立节点，通过服务名来自定义登录时的名称 root@xxxxx

IPC namespace

进程间通信的 IPC 资源也需要进行隔离，在同一个 IPC namespace 下的进程彼此之间沟通的全局ID可见，不在同一 namespace 下的则不可见

PID namespace

对进程PID进行隔离，不同 namespace 下的进程可以有相同的 PID，内核会为 PID namespace 维护一个树状结构，在命名空间下重新挂载 /proc 只会发现同属一个命名空间的其他进程

父可以看到子，根命名空间可以看到所有的进程查看所有 container 状态的原理：监控 docker daemon 所在 PID namespace 下所有进程和子进程，再根据条件进行筛选即可

如果需要在 docker 容器中跑多个进程，最先启动的应该是 bash，因为它具有资源监控与回收等管理能力

如果命名空间下的 init 没有处理某个信号，那么同下的其他进程发送的信号都会被屏蔽，这样可以防止 init 进程被误杀

一旦 init 进程被销毁，同下的进程也都会被销毁并回收

如果只想在 ps 的时候只看到该空间下的进程，需要对 /proc 进行重新挂载，在这种情况下，如果没有 mount namespace 进行挂载隔离的话，会影响到宿主的根空间

Docker 原理剖析

Mon, 26 Jan 2026 00:00:00 +0000

Namespaces

命名空间 (namespaces) 是 Linux 为我们提供的用于分离进程树、网络接口、挂载点以及进程间通信等资源的方法，这是实现进程间隔离的核心技术，通过配置不同的命名空间我们能够在创建新进程的时设置新进程应该在哪些资源上与宿主机器进行隔离

docker run 或者 docker start 不仅会设置进程相关的命名空间，还会设置与用户、网络、IPC 以及 UTS 相关的命名空间，通过命名空间成功完成了与宿主机进程和网络的隔离

解决了进程、网络以及文件系统的隔离

网络

每一个使用 docker run 启动的容器其实都具有单独的网络命名空间，Docker 为我们提供了四种不同的网络模式，Host、Container、None 和 Bridge 模式，Docker 还会为所有的容器设置 IP 地址。当 Docker 服务器在主机上启动之后会创建新的虚拟网桥 docker0，随后在该主机上启动的全部服务在默认情况下都与该网桥相连

默认情况下，每一个容器在创建时都会创建一对虚拟网卡，两个虚拟网卡组成了数据的通道，其中一个会放在创建的容器中，会加入到名为 docker0 网桥中

当有 Docker 的容器需要将服务暴露给宿主机器，就会为容器分配一个 IP 地址，同时向 iptables 中追加一条新的规则，经过 iptables 的 NAT PREROUTING 将 ip 地址重定向

libnetwork

它提供了一个连接不同容器的实现，同时也能够为应用给出一个能够提供一致的编程接口和网络层抽象的容器网络模型

挂载点

解决文件目录访问的问题在新的进程中创建隔离的挂载点命名空间需要在 clone 函数中传入 CLONE_NEWNS，这样子进程就能得到父进程挂载点的拷贝，如果不传入这个参数子进程对文件系统的读写都会同步回父进程以及整个主机的文件系统。

如果一个容器需要启动，那么它一定需要提供一个根文件系统（rootfs），容器需要使用这个文件系统来创建一个新的进程，所有二进制的执行都必须在这个根文件系统中

为了保证当前的容器进程没有办法访问宿主机器上其他目录，我们在这里还需要通过 libcontainer 提供的 pivot_root 或者 chroot 函数改变进程能够访问个文件目录的根节点

CGroups

用来解决物理资源的隔离问题 Linux 的 CGroup 能够为一组进程分配资源，也就是我们在上面提到的* CPU、内存、网络带宽等资源*

层级结构，利用 VFS 的抽象接口替换成具体的实现

在 CGroup 中，所有的任务就是一个系统的一个进程，而 CGroup 就是一组按照某种标准划分的进程，在 CGroup 这种机制中，所有的资源控制都是以 CGroup 作为单位实现的，每一个进程都可以随时加入一个 CGroup 也可以随时退出一个 CGroup

把进程加入到 cgroups 子节点也有多种方法，可以直接把 pid 写入到子节点下面的 task 文件中

UnionFS

解决镜像打包的问题 Docker 镜像其实本质就是一个压缩包，Docker 镜像就是一个文件

Docker 中的每一个镜像都是由一系列只读的层组成的，Dockerfile 中的每一个命令都会在已有的只读层上创建一个新的层

容器和镜像的区别：所有的镜像都是只读的，而每一个容器其实等于镜像加上一个可读写的层，也就是同一个镜像可以对应多个容器

正则表达式快速入门

Mon, 26 Jan 2026 00:00:00 +0000

应用场景：有关字符串的搜索，替换，验证，过滤正则表达式语言是一种内置于程序设计语言中的一种迷你语言

演示实例将使用 JS 和 Go 来进行展示不同语言对正则的实现会有所区别

如何让匹配更精准？制定更严格的模式串来约束匹配结果，使得我们不会匹配到一些不想要的结果

同一匹配目的但实现有区别

匹配多个

js 中使用 g 的标志来匹配多个 go 中使用 FindAll 的方法来匹配多个

大小写

js 中使用 i 的标志位来忽略大小写 go 中需要在模式串前加 (?i)

匹配任意字符

. 匹配任意单个字符，如果要单独匹配 . 字符就需要转义成 \.

匹配一组字符

使用元字符 [ 和 ] 来定义字符集合如果里面只有字母，则表示单个字符匹配集合中的任意一个字符，例如 [ab] 表示匹配 a 字母开头或 b 字母使用这种方式也可以达到局部不区分大小写的匹配效果，如 [Aa]

除了一个个枚举字符区间，正则提供了 - 连字符来简化区间的表达，例如 [0-9] [A-Z] 等，连字符只有在 [] 中才有特殊意义，多个连字符表示的区间可以拼接在一起，例如 [A-Za-z0-9]

使用 ^ 可以对字符区间进行取非匹配，例如除数字以外的字符 [^0-9] 如果要匹配 + 和 . 在区间中不需要转义

单独一个字符也可以写作字符集合，在后面有加号或者星号的时候能增加可读性

元字符

包括 . [ ] \ + * ? { } ( ) | 如果要匹配这些字符需要加上 \ 进行转义还有匹配空白字符的空白元字符 [\b] \f \n \r t \v

匹配特定字符类别

这些表示字符类别的元字符能够简化区间的表达从而简化整个模式串

\d 等价于 [0-9] \D 等价于 [^0-9] 一般来说大写字母表示取非

\w 表示任何一个无大小写差别字母数字或下划线 \W 同理可得

匹配空白字符

\s 任何一个空白字符，等价于 [\f\n\r\t\v] \S 同理可得

匹配多个字符

只需要在字符集合的后面附上一个 + 号，就可以按照同样的规则匹配至少一个字符如果使用 * 号，则可以满足无字符的情况，表示匹配0个或多个字符

匹配0个或1个

后接 ? 可以匹配0个或者1个这个字符来表示可选匹配，例如 https? 既能匹配 http 又能匹配 https

限定匹配的重复次数

因此引入 { 和 } 元字符来限制匹配次数

重复确定的值：{3} 表示前一个字符重复3次算一次匹配例如：#[[:xdigit]]{6} 用于匹配色值

重复一个范围内的次数：{最小值,最大值} 最小值可以是0，? 相当于 {0,1}

至少重复 k 次：{k,}

贪婪型和懒惰型元字符

默认的 + + {n, } 都是贪婪型元字符，它们会尝试匹配尽量多的字符，在目标串中有模式串的子串嵌套的时候贪婪模式会不适用，本来能得到多个目标串的却只能得到一个

懒惰型元字符会尝试匹配尽量少的字符，启用懒惰模式只需要在贪婪型元字符后加上 ? 即可例如匹配超链接标签 <a href=".*?"><\/a>

位置匹配

用来确定在什么地方进行匹配操作，限定匹配的位置

边界限定符

一些特殊的元字符可以指定匹配操作在什么位置发生

单词边界 \b 用来匹配一个单词的开始或结尾，本质上是 \w 和 \W 之间例如 \bbuild\b 就不会匹配到 building

如果要匹配一个完整的单词，前后都必须加上 \b ，如果只是匹配以某串开始或结尾就只需要在对应的位置上加上 \b 即可同理 \B 匹配非单词边界

字符串边界 ^ 在字符集合外匹配字符串的开头而 $ 匹配字符串的末尾例如：匹配 xml 文档的开头标签 ^\s*<\?xml .*?\?> ，\s* 表示允许开头可以有0个或者多个空白字符

分行匹配模式

最开头加上 (?m) 能够开启分行匹配模式，^ 不仅可以匹配正常字符串的开头，还能够匹配换行后的开始位置需要了解具体实现是否支持此模式

子表达式

把一个表达式划分成多个子表达式，并用 () 围起来，这使得这些子表达式能够被当做一个独立的元素（字符）来使用，即便是短语也可以当做一个字符来进行处理

例如：简单匹配IP地址 (\d{1,3}\.){3}\d{1,3} 先匹配三个连续的 xxx. 然后再匹配最后一个 xxx

为了提高可读性可以给每一个子表达式都使用括号，但是不同的实现可能会导致匹配性能的下降

串的集合匹配可以使用 (串1|串2|串3) 的方式来进行匹配，| 表示或

子表达式嵌套

对于严格定义的 IP 地址来说，需要使用多个表达式嵌套的方式来进行更严格的匹配

考虑数字的位数以及开头的数字的要求，不难写出这样的嵌套表达式

^(((\d{1,2})|(1\d{2})|(2[0-4]\d)|(25[0-5]))\.)(((\d{1,2})|(1\d{2})|(2[0-4]\d)|(25[0-5]))\.){2}((\d{1,2})|(1\d{2})|(2[0-4]\d)|(25[0-5]))$

回溯引用

这允许了模式串引用前面的匹配结果，达到某种程度上的前后一致匹配

通过 \N 的方式，我们可以直接引用模式串中的第 N 个子表达式，N从1开始，使得我们的匹配产生一定的关联性。子表达式需要用圆括号括起来，如果N为0，那么则代表整个表达式

例如：[ ]+(\w+)[ ]+\1 等价于 [ ]+(\w+)[ ]+(\w+) 加上前后的 (\w+) 必须一致的约束

值得注意的是目前 Go 内置的正则引擎暂时不支持此特性，JS 是支持这种用法的

使用回溯引用进行替换

一个搜索模式和一个替换模式总共两个模式串可以完成较为复杂的替换功能

在JS下可以在替换模式中使用 $N 的方式可以引用第 N 个子表达式匹配到的内容从而拼接出我们期望的新串

这种特性经常用于字符串的重排版

使用元字符来进行新串的大小写转换

使用 \U 或 \L 作为起始，以 \E 作为结束，中间的串都会被转换成大写或小写

使用 \u 和 \l 只能把下一个字符（或子表达式）转化为大小写

前后查找

从匹配的模式串中提取我们关心的那一部分结果需要使用前后匹配常见的实现都支持向前查找，JS 不支持向后查找，其他大多数语言支持向后查找

任何一个子表达式都可以转换为一个向前查找表达式，只要加上 ?= 前缀即可，表示只要这个表达式之前的结果同理 ?<= 表示只要这个表达式之后的结果（向后查找）

例如：只提取金额后面的数字 (?<=\$)[0-9.]+

嵌入条件

并非所有的实现都支持条件处理

回溯引用条件

只在一个前面的子表达式搜索成功时才允许使用这个表达式语法：(?(N)子表达式) 表示当第N个表达式搜索成功时，才会执行这个括号内的表达式

搭配使用方式：((?(N)表达式1)|表达式2) 可以达到语义上的 if N: 表达式1 else: 表达式2 类似条件语句的效果

前后查找条件

只需要把回溯引用编号改为向前查找或者向后查找表达式即可可以表达要么都出现要么都不出现的条件语义（使用可选表达式也能达到目的）例如：``(?(?=-)-\d{4})``` 向前查找 - ，如果成功，再多匹配四位数字

上下文工程中提示词编写的原则和技巧

Sun, 12 Oct 2025 15:40:09 +0000

摘要自anthropic：Effective context engineering for AI agents

引言：从单一提示到上下文状态管理

在构建复杂的 AI 智能体（Agent）时，我们关注的焦点已不再仅仅是如何写出“魔法”般的提示词（Prompt）。大型语言模型（LLM）的推理过程是一个多轮、动态的状态管理过程。因此，我们需要从“提示工程”（Prompt Engineering）迈向上下文工程（Context Engineering）。

提示工程侧重于如何编写和组织 LLM 指令以获得最佳结果。而上下文工程，作为提示工程的自然演进，则关注于在 LLM 推理过程中策划和维护最优的代币集合（信息）的整套策略。系统提示（System Prompts）是 Agent 初始、静态上下文的核心组成部分，其编写质量直接决定了 Agent 的初始效用和指导方向。

有效的上下文工程要求我们“在上下文中思考”（thinking in context），即如何利用有限的上下文窗口，找到最小可能集合的高信号代币，最大限度地提高所需结果的可能性。

提示词编写的核心原则：清晰性与极简主义

上下文（Context）是 Agent 的有限资源，因为它受到 LLM 的注意力预算（attention budget）和上下文衰减（context rot）等架构约束。因此，对系统提示的要求是高效且紧凑。

极度清晰和直接的语言

系统提示应该极其清晰（extremely clear），并使用简单、直接的语言来呈现 Agent 的指导信息。

追求最小化信息集合

无论您如何组织系统提示，都应该努力实现信息的最小化集合，这个集合必须充分概述您期望的 Agent 行为。

请注意，这里的“最小化”（minimal）不一定意味着简短。您仍然需要预先为 Agent 提供足够的信息，以确保它能够坚持您期望的行为。我们的总体指导原则是深思熟虑，并保持上下文内容丰富，但同时又紧凑（informative, yet tight）。

最佳实践：最好从一个最小化的提示开始测试，并使用可用的最佳模型来观察其在任务上的表现。然后，根据在初始测试中发现的失败模式，迭代性地添加清晰的指令和示例来改进性能。

关键技巧：定位“正确的高度”（The Right Altitude）

“正确的高度”是 Agent 开发者在编写提示时需要掌握的“金发姑娘区”（Goldilocks zone）。它要求我们在两种常见的失败模式之间取得平衡：

失败模式一：过于僵化（硬编码的复杂逻辑）

特点： 工程师试图在提示中硬编码复杂、脆弱的逻辑，以引发精确的 Agent 行为。
后果： 这种方法会随着时间的推移，增加系统的脆弱性和维护的复杂性。
示例（避免）： 像“如果工具 A 返回了 HTTP 404 错误，并且用户在过去 5 分钟内没有提及‘重试’，那么你必须调用工具 B，且将 query 参数设置为用户消息的前 10 个词，除非用户消息包含 URL”——这种脆弱的 If-Else 逻辑应该被避免。

失败模式二：过于笼统（模糊的指导）

特点： 工程师提供模糊、高层的指导，未能为 LLM 提供具体的信号以指导期望的输出，或者错误地假设 Agent 具有共享的上下文。
后果： Agent 可能会偏离目标，无法做出有效的、符合预期的行动。
示例（避免）： 像“做一名优秀的助手，帮助用户解决问题”——这种提示过于笼统，难以有效指导行为。

“正确的高度”的提示词

最优的高度是：足够具体以有效地指导行为，但同时要足够灵活，为模型提供强大的启发式方法来引导行为。

示例（理想的系统提示片段）：

Agent 角色与目标： “你是一名专业的技术文档分析师。你的首要目标是准确回答用户关于文档库的查询。你必须始终使用 search_documents 工具来获取最新的信息。如果信息来源不确定，你必须明确告知用户信息不足。”

约束与输出格式： “在回答之前，你必须在内部推理步骤中指出你使用的工具和检索到的信息。最终回答必须简洁，并且仅包含来自工具结果的信息。”

结构化提示：利用标记增强 Agent 可读性

为了避免提示内容混杂，提高 Agent 的理解效率，建议将提示组织成不同的部分（distinct sections）。

技巧：使用 XML 标签或 Markdown 标题进行划分

建议使用技术，如 XML 标签或 Markdown 标题来划分这些部分。这种结构化方法使得 LLM 能够更好地识别不同类型的信息，即使模型能力不断提升，这种清晰的划分仍是良好实践。

部分名称	标记示例	目的
背景信息	`<background_information>`	设定 Agent 的专业领域或限制条件。
指令	`<instructions>`	明确 Agent 必须遵循的步骤或行动规则。
工具指导	`## Tool guidance`	描述工具的使用方式、时机和优先级。
输出描述	`## Output description`	明确最终输出的格式要求（如 JSON、Markdown）。

少样本提示（Few-shot Prompting）的精心策展

提供示例（即少样本提示）是 Agent 开发中持续强烈建议的最佳实践。示例是 Agent 预期行为的视觉蓝图，对于 LLM 而言，示例有极大引导作用。

策展要点：

避免堆砌边缘案例： 不要试图将一大堆边缘案例清单塞入提示中，试图囊括 Agent 可能需要遵循的每一条规则。
提供规范化示例： 应该努力策划一组多样化、规范化的示例，以有效地描绘 Agent 的预期行为。这些示例应展示核心功能、正确的工具使用流程以及预期的响应风格。

通过以上这些技巧，Agent 开发者能够确保他们的系统提示在上下文工程的框架下，既能提供有效的指导信号，又能尊重 LLM 有限的注意力预算，从而构建出更可靠、高效的 Agent。

编写高效工具的最佳实践指南(精华版)

Sat, 13 Sep 2025 11:40:03 +0000

原文来自anthropic：Writing effective tools for agents — with agents

本文概述了为AI代理构建高效工具的关键策略，强调了工具对代理效能的重要性。文章详细介绍了如何通过原型构建、综合评估以及与AI代理（如Claude Code）协作来优化工具。它还阐述了编写高质量工具的原则，包括选择合适的工具、进行命名空间管理、返回有意义的上下文、优化令牌效率以及进行提示工程。最终目标是使代理能够更直观、高效地解决现实世界中的各种任务。

简介

AI代理的效能与其所使用的工具质量息息相关。在传统软件开发中，我们为确定性系统编写软件，例如 getWeather("NYC") 总是以相同方式获取天气信息。然而，工具是连接确定性系统与非确定性代理之间的新型软件契约。代理可能会调用工具、利用通用知识或提出澄清问题来响应用户查询，甚至可能出现幻觉或无法理解如何使用工具。这意味着我们需要从根本上重新思考为代理编写软件的方法，并以代理为中心进行设计。

本指南将为您提供一套行之有效的方法和原则，帮助您构建、评估和优化高质量的代理工具，从而扩大代理在解决广泛任务方面的有效性范围。

核心方法论：构建、评估与协作优化

编写高效工具是一个迭代过程，涉及构建原型、运行全面评估以及与代理协作优化工具。

构建原型 (Building a prototype)
- 快速启动：首先快速建立工具原型，以便亲身体验哪些工具对代理“符合人体工程学”。
- 提供文档：如果您使用像 Claude Code 这样的代理来编写工具，提供其依赖的任何软件库、API 或 SDK 的文档会非常有帮助，尤其是 LLM 友好的平面文本文档（如 llms.txt 文件）。
- 本地测试与反馈：将工具包装在本地 MCP 服务器或桌面扩展 (DXT) 中，连接到 Claude Code 或 Claude Desktop 应用进行测试。亲自测试以发现问题，并收集用户反馈，以建立对预期用例和提示的直觉。
运行评估 (Running an evaluation)
- 系统性衡量性能：评估能系统地衡量工具性能。
- 生成评估任务：
  - 以真实世界用途为基础：生成大量基于真实世界用例的评估任务。提示应来源于实际数据源和服务（例如内部知识库和微服务），避免过于简单或肤浅的“沙盒”环境，因为它们无法充分测试工具的复杂性。强大的评估任务可能需要多次工具调用。
  - 强任务示例：
    - “下周与 Jane 安排一次会议，讨论我们最新的 Acme Corp 项目。附上我们上次项目规划会议的记录并预订一个会议室。”
    - “客户 ID 9182 报告说他们一次购买尝试被收取了三次费用。查找所有相关的日志条目并确定是否有其他客户受到相同问题的影响。”
    - “客户 Sarah Chen 刚刚提交了取消请求。准备一份挽留方案。确定：(1) 他们为什么离开，(2) 什么挽留方案最具吸引力，(3) 在提供方案前我们应该注意哪些风险因素。”
  - 弱任务示例：
    - “下周与 jane@acme.corp 安排会议。”
    - “搜索支付日志中的 purchase_complete 和 customer_id=9182。”
    - “查找客户 ID 45892 的取消请求。”
  - 可验证的响应：每个评估提示都应与一个可验证的响应或结果配对。验证器可以是从精确字符串比较到让 Claude 判断响应的复杂工具。避免过于严格的验证器，它们可能因为格式、标点符号或有效的替代措辞等细微差异而拒绝正确响应。
  - 可选的预期工具调用：您可以选择为每个提示-响应对指定代理在解决任务时预期调用的工具，以衡量代理在评估中是否成功理解每个工具的用途。但要避免过度指定或过度拟合策略，因为可能存在多种解决任务的有效路径。
- 程序化运行评估：建议使用直接的 LLM API 调用以程序化方式运行评估。对每个评估任务使用简单的代理循环（while 循环封装交替的 LLM API 和工具调用）。
- 收集多维度指标：除了顶级准确性，还建议收集其他指标，例如单个工具调用和任务的总运行时间、工具调用的总次数、总令牌消耗以及工具错误。跟踪工具调用有助于揭示代理遵循的常见工作流程，并为工具整合提供机会。
- 系统提示引导思考：在评估代理的系统提示中，建议指示代理不仅输出结构化响应块（用于验证），还输出推理和反馈块。在工具调用和响应块之前输出这些内容，可以通过触发思维链（CoT）行为来提高 LLM 的有效智能。
分析结果 (Analyzing results)
- 代理是重要伙伴：代理是发现问题和提供反馈的有用伙伴，反馈内容可以从矛盾的工具描述到低效的工具实现和令人困惑的工具模式。
- 解读代理行为：观察代理在哪里受阻或困惑。仔细阅读评估代理的推理和反馈（或 CoT）以发现问题。审查原始记录（包括工具调用和工具响应），以捕捉代理 CoT 中未明确描述的任何行为。记住，代理并不一定知道正确答案和策略，需要“字里行间”地理解。
- 分析工具调用指标：
  - 过多的冗余工具调用可能表明需要调整分页或令牌限制参数。
  - 因无效参数而导致的工具错误可能表明工具需要更清晰的描述或更好的示例。
  - 示例：Claude 的网页搜索工具曾不必要地在 query 参数中附加“2025”，导致搜索结果偏差和性能下降。通过改进工具描述，引导 Claude 走向正确的方向。
与代理协作优化 (Collaborating with agents)
- 让代理分析和改进工具：您可以让代理分析评估结果并自行改进工具。只需将评估代理的记录连接起来，然后粘贴到 Claude Code 中即可。Claude 擅长分析记录并一次性重构大量工具，例如，确保在进行新更改时工具实现和描述保持自洽。
- Anthropic 团队的大部分建议都来自于使用 Claude Code 反复优化其内部工具实现。他们使用保留测试集来避免对“训练”评估过度拟合，并发现即使在“专家”工具实现（无论是人工编写还是 Claude 生成）之外，也能提取额外的性能改进。

编写高效工具的关键原则

从上述过程中，Anthropic 提炼出以下编写高效工具的指导原则：

选择正确的工具 (Choosing the right tools for agents)
- 少即是多，聚焦高影响力：工具并非越多越好。一个常见错误是仅仅封装现有软件功能或 API 端点，而不考虑工具是否适合代理。
- 理解代理的“可供性”：LLM 代理的“上下文”有限（即它们一次可以处理的信息量有限）。如果一个代理使用返回所有联系人的工具，然后逐个令牌地阅读，它会将有限的上下文空间浪费在不相关的信息上。
- 优先考虑上下文关联性：例如，在地址簿案例中，应实现 search_contacts 或 message_contact 工具，而不是 list_contacts 工具。
- 整合功能：工具可以整合功能，在底层处理多个离散操作（或 API 调用）。例如，工具可以丰富响应相关的元数据，或者在单个工具调用中处理经常链式调用的多步任务。
  - 示例：
    - 与其实现 list_users、list_events 和 create_event 工具，不如考虑实现一个能够查找可用性并安排事件的 schedule_event 工具。
    - 与其实现 read_logs 工具，不如考虑实现一个只返回相关日志行和一些上下文的 search_logs 工具。
    - 与其实现 get_customer_by_id、list_transactions 和 list_notes 工具，不如实现一个能够一次性编译客户所有近期和相关信息的 get_customer_context 工具。
- 明确且独特的目标：确保每个工具都有清晰、独特的目标。工具应该使代理能够像人类一样（在访问相同底层资源的情况下）细分和解决任务，同时减少因中间输出而消耗的上下文。
- 避免冗余和干扰：过多的工具或功能重叠的工具会分散代理的注意力，使其无法采取高效策略。仔细、有选择地规划您构建（或不构建）的工具，可以带来巨大回报。
命名空间化您的工具 (Namespacing your tools)
- 解决功能重叠和模糊性：代理可能会访问数十个 MCP 服务器和数百个不同工具。当工具功能重叠或目的模糊时，代理会感到困惑。
- 使用前缀分组：命名空间（将相关工具分组在公共前缀下）有助于划定工具之间的界限。例如，按服务（如 asana_search、jira_search）和资源（如 asana_projects_search、asana_users_search）对工具进行命名空间化，可以帮助代理在正确的时间选择正确的工具。
- 考虑前缀与后缀：前缀和后缀命名空间的选择对工具使用评估有显著影响，效果因 LLM 而异。建议根据您自己的评估选择命名方案。
- 降低代理错误风险：通过有选择地实现名称能反映任务自然细分的工具，您可以同时减少加载到代理上下文中的工具数量和工具描述，并将代理的计算从代理上下文卸载回工具调用本身，从而降低代理犯错的总风险。
从工具返回有意义的上下文 (Returning meaningful context from your tools)
- 高信号信息优先：工具实现应注意只向代理返回高信号信息。
- 语境相关性优先于灵活性：应优先考虑语境相关性，避免低级技术标识符（例如：uuid、256px_image_url、mime_type）。像 name、image_url 和 file_type 这样的字段更有可能直接影响代理的后续动作和响应。
- 使用自然语言而非神秘标识符：代理处理自然语言名称、术语或标识符通常比处理神秘标识符成功得多。将任意字母数字 UUID 解析为更具语义意义和可解释性的语言（甚至是 0 索引 ID 方案），能显著提高 Claude 在检索任务中的精确度，减少幻觉。
- 灵活的响应格式：在某些情况下，代理可能需要灵活性来处理自然语言和技术标识符输出，即使只是为了触发下游工具调用。您可以通过在工具中暴露一个简单的 response_format 枚举参数来实现这一点，允许代理控制工具返回“简洁（concise）”还是“详细（detailed）”的响应。
  - 示例：
    - Slack 线程和回复由唯一的 thread_ts 标识，这是获取线程回复所必需的。thread_ts 和其他 ID（channel_id、user_id）可以从“详细”工具响应中检索，以启用需要这些 ID 的进一步工具调用。“简洁”工具响应仅返回线程内容，不包括 ID。在这种情况下，使用“简洁”工具响应可以节省约 ⅓ 的令牌。
- 优化响应结构：工具响应结构（例如 XML、JSON 或 Markdown）也会影响评估性能。LLM 在与其训练数据匹配的格式下表现更好，因此最佳响应结构会因任务和代理而异。建议根据您的评估选择最佳响应结构。
优化工具响应的令牌效率 (Optimizing tool responses for token efficiency)
- 质量与数量并重：优化上下文质量固然重要，但优化工具响应中返回给代理的上下文数量也同样重要。
- 实现分页、范围选择、过滤和/或截断：对于可能消耗大量上下文的工具响应，建议实现分页、范围选择、过滤和/或截断的某种组合，并设置合理的默认参数值。例如，Claude Code 默认将工具响应限制为 25,000 令牌。
- 截断后的引导：如果选择截断响应，请务必用有用的指令引导代理。直接鼓励代理采取更节省令牌的策略，例如进行多次小而有针对性的搜索，而不是一次广泛的搜索。
- 有帮助的错误响应：如果工具调用引发错误（例如，在输入验证期间），应通过提示工程来设计错误响应，以清晰地传达具体且可操作的改进，而不是不透明的错误代码或堆栈跟踪。
  - 示例：
    - 无用的错误响应：例如仅返回错误代码。
    - 有用的错误响应：清晰指出参数问题，并提供正确格式的示例，引导代理进行修正。
  - 工具截断和错误响应可以引导代理采取更节省令牌的工具使用行为（使用过滤器或分页），或提供正确格式的工具输入示例。
提示工程您的工具描述和规范 (Prompt-engineering your tool descriptions)
- 最有效的方法之一：这是提高工具效率最有效的方法之一。工具描述和规范会加载到代理的上下文中，可以共同引导代理采取有效的工具调用行为。
- 像描述给新员工一样：编写工具描述和规范时，想象您会如何向团队新员工描述您的工具。明确您可能隐含的上下文——专业的查询格式、特定术语的定义、底层资源之间的关系。
- 避免歧义：通过清晰描述（并使用严格的数据模型强制执行）预期的输入和输出，避免歧义。特别是，输入参数应明确命名：例如，不要使用 user，尝试使用 user_id。
- 评估验证效果：通过评估可以更自信地衡量提示工程的影响。即使是对工具描述的微小改进，也能带来显著的性能提升。例如，Claude Sonnet 3.5 通过对工具描述进行精确改进，在 SWE-bench Verified 评估中取得了最先进的性能，显著降低了错误率并提高了任务完成度。
- 查阅更多资源：您可以查阅 Anthropic 的开发者指南了解更多工具定义最佳实践。如果您正在为 Claude 构建工具，还建议阅读关于工具如何动态加载到 Claude 系统提示中的信息。对于 MCP 服务器工具，工具注解有助于披露哪些工具需要开放世界访问或进行破坏性更改。

展望

为了为代理构建高效工具，我们需要将软件开发实践从可预测的确定性模式重新定位到非确定性模式。通过本文描述的迭代、评估驱动的过程，我们发现了一些使工具成功的持续模式：高效的工具是经过有意且清晰定义的，能明智地利用代理上下文，可组合成多样化的工作流程，并使代理能够直观地解决现实世界任务。

随着代理能力的增强，我们通过系统化、评估驱动的方法改进工具，可以确保它们所使用的工具也能随之发展。

提示词技巧之元提示

Sun, 08 Jun 2025 22:04:45 +0000

介绍元提示词的概念和应用，通过模版化和反馈迭代机制，帮助生成更高质量的AI提示词，提高大语言模型的输出效果。

背景

为什么要使用元提示？

不同模型在同个字词下的权重以及遵循情况不同，有些在特定模型优化过的提示词，在别的模型上运行效果不见得符合预期
很多提示词工程中的技巧并没有固定的章法，不知道自己写的提示词到底要如何优化
让人把所有的条件边界都用自然语言定义清楚，本身就是一件反人类的事情，我们需要一种可操作的“反馈+优化”的手段

目的：减轻人的负担，避免凭感觉去不断修改尝试调试提示词

什么是元提示词？

类似编程语言中的元编程的概念，元提示词是"用于生成提示词"的模版提示词，也就是俗称的万金油提示词，你可以通过使用这个泛化的模版，让AI特化生成出更具体的，质量更高的提示词。

要使用元提示生成更高质量的回答，一般分成这2个核心步骤。

使用元提示词得到一个已经经过大模型优化过的提示词
复制大模型生成的提示词作为用户的prompt，再驱动大模型根据这个提示词进行回答

常见的元提示词模版

来源自Deepseek的提示库

你是一位大模型提示词生成专家，请根据用户的需求编写一个智能助手的提示词，来指导大模型进行内容生成，要求：
1. 以 Markdown 格式输出
2. 贴合用户需求，描述智能助手的定位、能力、知识储备
3. 提示词应清晰、精确、易于理解，在保持质量的同时，尽可能简洁
4. 只输出提示词，不要输出多余解释

请帮我生成一个“Linux 助手”的提示词

来自外网的英文版本

You are a wizard prompt engineer. You write very bespoke, detailed, and succinct
prompts. I want you to write me a prompt that will {{task}}

{{task}}:a blog about importance of LLM with seo optimization

instructions
- output the prompt you generate in markdown
- output the prompt in a code block

生成测试用例的元提示词

You are a prompt engineer specializing in software testing. You write detailed，
comprehensive, and precise prompts for generating test scenarios. I want you
to write me a prompt that will {{task}}.

Instructions：
- Output the prompt you generate in markdown
- Output the prompt in a codeblock
- Ensure the prompt covers functional, non-functional, positive, and negative
test scenarios
- Add guidance for generating both manual and automated test cases

{{task}}：Generate corgprehensive test scenarios for a user login feature

我自己仿写了一个中文版本的元提示词，同时加上对提示词进行反馈迭代的机制，这样就能在第一步的时候通过让模型反馈让自动去调整生成的提示词。适用于通义千问以及deepseek这样的国产优秀大模型。

你是一位资深的LLM提示词工程师，能够生成最符合定制要求，精准且简洁的提示词，你的任务是生成满足 {{task}} 的最佳提示词

{{task}}: <定义你自己的任务>

instructions:
- 将markdown格式的提示词完整放置在代码块内
- 问我5个能帮助你更好地生成最佳提示词的问题
- 根据反馈，重复执行上述步骤不断优化你生成的提示词

具体例子：

你是一位资深的LLM提示词工程师，能够生成最符合定制要求，精准且简洁的提示词，你的任务是生成满足 {{task}} 的最佳提示词

{{task}}: 你是一位经验丰富的高考语文老师，请阅读下面的材料，根据要求写一篇满分作文。

他想要给孩子们唱上一段，可是心里直翻腾，开不了口。

——老舍《鼓书艺人》

假如我是一只鸟，

我也应该用嘶哑的喉咙歌唱

——艾青《我爱这土地》

我要以带血的手和你们一一拥抱，

因为一个民族已经起来

——穆旦《赞美》

以上材料引发了你怎样的联想和思考？请写一篇文章。

要求：选准角度，确定立意，明确文体，自拟标题；不要套作，不得抄袭；不少于800字。

instructions:
- 将markdown格式的提示词完整放置在代码块内
- 问我5个能帮助你更好地生成最佳提示词的问题
- 根据反馈，重复执行上述步骤不断优化你生成的提示词

经过反馈优化输出的提示词样例：

你是一位经验丰富、擅长写作高考语文议论文的教师，请严格按照高考满分作文的标准写作。

**任务说明：**

请阅读下列材料，并根据写作要求写一篇议论文，立意深刻，结构严谨，语言凝练，逻辑清晰，风格理性思辨，体现思想高度。

---

材料如下：

他想要给孩子们唱上一段，可是心里直翻腾，开不了口。  
——老舍《鼓书艺人》

假如我是一只鸟，  
我也应该用嘶哑的喉咙歌唱  
——艾青《我爱这土地》

我要以带血的手和你们一一拥抱，  
因为一个民族已经起来  
——穆旦《赞美》

---

**写作要求：**

1. 选准角度，提出明确立意，观点鲜明；
2. 文体为议论文，不得写成记叙文、散文等其他文体；
3. 语言表达规范，文风凝练，体现思辨性与逻辑性；
4. 结构完整，层次清晰，有典型的引论—本论—结论结构；
5. 不套作，不抄袭；
6. 字数不少于800字；
7. 作文风格须具备“高考满分作文”特征，如：
   - 紧扣材料主题，立意深刻；
   - 善用名言事例、类比对比、层层递进等论证方式；
   - 表达有力量，句式有变化；
   - 有思想深度、有社会关怀；
   - 标题醒目有力。

---

请生成一篇符合以上所有要求的高考议论文，输出格式为：  
【标题】  
【正文】

最后将输出的提示词作为输入，最终得到一篇完整的作文

【以生命之声，回应时代之问】

【正文】

在时代风云变幻的洪流中，总有一些声音，穿透历史的尘埃，震撼人心。老舍笔下的鼓书艺人，欲唱却哽咽难出，是悲悯现实的沉痛；艾青以嘶哑喉咙歌唱，是对土地深沉的热爱；穆旦以“带血的手”拥抱民族，是对复兴的庄严宣告。他们用各自的方式，回应时代之问，传递个体的担当。由此可见，当个体生命与历史遭遇，真正有价值的声音，不是空洞的呐喊，而是深沉的共鸣——**以生命之声，回应时代之问，这是个体的觉醒，更是民族的希望。**

回应时代，并非轻巧的表态，而是以血肉之身，融入时代的剧烈脉动之中。老舍笔下的艺人“心里直翻腾，开不了口”，看似沉默，却正是时代苦难在个体心灵中的真实回响。沉默不是逃避，而是内心巨大的情感张力。这种沉重的沉默，是对现实最深切的批判，也是一种“说不出的呐喊”。正如哲人维特根斯坦所言：“凡不能言说的，就应沉默。”沉默中藏着痛苦的体悟，也孕育着更有力量的表达。真正的回应，不仅在于声音的响亮，更在于情感的真挚与思想的深刻。

与之相对，艾青的“嘶哑的喉咙”却毫不退缩。纵使声带破碎，也要以歌唱见证土地的苦难与希望。这是一种近乎悲壮的诗性担当，是诗人与人民命运共振的艺术实践。艾青没有回避伤痕，而是用受伤的声音去歌唱受伤的土地。他的选择不仅是一种表达，更是一种姿态——用诗性的力量击碎麻木，用理想的光芒照亮黑暗。这种在困厄中坚持歌唱的精神，是对个体良知与社会责任最动人的表达。

而穆旦则将个体情感上升到民族层面，“以带血的手和你们一一拥抱”，是饱经战争与苦难后对希望的激烈呼唤。这不仅是诗人情感的释放，更是时代力量的凝聚。当个体不再只是旁观者，而以血肉之躯参与历史的洪流时，回应时代便不再是抽象的责任，而是内化于心的使命感。这种主动投身时代、唤醒民族意识的行为，正是一个民族复苏的象征。

现实语境中，这样的精神依旧具有强烈的现实意义。当今时代，青年一代身处信息洪流之中，面对复杂的社会议题，或沉默，或喧哗，但真正需要的，是发自内心、扎根现实的理性之声。是韩愈所说“知其不可而为之”的执拗，是鲁迅“我以我血荐轩辕”的担当。面对气候危机、技术伦理、社会公平等问题，青年不能只是围观者、评论者，更应是思考者、行动者。唯有将个体命运与时代大义深度连接，方能发出穿透人心的强音。

我们不能忽视，回应时代并不总是轰轰烈烈。有时是一位乡村教师几十年如一日的坚守，是一位科研工作者在实验室默默耕耘，是一位普通公民在社区中尽己所能的参与。这些微小的力量汇聚在一起，便是社会进步的脉搏，是历史温度的来源。

正如黑格尔所言：“一个民族有一群仰望星空的人，他们才有希望。”仰望星空的人，并不脱离土地，他们脚踏现实，以生命之声回应时代之问。他们的声音或许微弱，但因承载真实与信仰，终将响彻时代的回廊。

【结语】

每一个身处时代洪流中的个体，都是鼓书艺人，是艾青，是穆旦。选择沉默或歌唱，挣扎或前行，终究无法回避的是：你将如何回应这个时代？我们应当以更坚定的姿态、更深沉的情感、更理性的思辨，回应历史、回应社会、回应良知。惟其如此，个体之声才能汇入民族的合唱，时代之问才能迎来最铿锵的答案。

同时这种元提示词，还能够生成适用于多模态图片分析的prompt

以股票K线图分析为例子

你是一位资深的LLM提示词工程师，能够生成最符合定制要求，精准且简洁的提示词，你的任务是生成满足 {{task}} 的最佳提示词

{{task}}: 仔细查看并分析提供的股票最近6个月的日K线图，并给出未来中长期的支撑位以及压力位的价格点位

instructions:
- 将markdown格式的提示词完整放置在代码块内
- 问我5个能帮助你更好地生成最佳提示词的问题
- 根据反馈，重复执行上述步骤不断优化你生成的提示词

总结

元提示词作为一种高效的提示词工程技巧，为我们提供了一种系统化、可迭代优化的方法来生成更高质量的提示词。通过本文的分享，我们了解到：

元提示词的价值
- 解决了不同模型对提示词理解差异的问题
- 提供了一种可操作的提示词优化机制
- 减轻了人工编写和调试提示词的负担
核心应用步骤
- 使用元提示词模板生成优化后的提示词
- 将生成的提示词作为实际输入来获取最终结果
- 通过反馈机制不断改进提示词质量
实践应用场景
- 文本创作（如高考作文）
- 多模态分析（如股票技术分析）
- 专业领域问答
- 测试用例生成

通过元提示词技术，我们可以更好地发挥大语言模型的潜力，提高输出质量，同时也为提示词工程提供了一个更加系统化和可控的方法论。这不仅能提高我们使用AI的效率，也能帮助我们获得更加准确和有价值的输出结果。

CGO封装CPP库的一些最佳实践

Sun, 27 Mar 2022 00:00:00 +0000

背景

最近业务上需要复用CPP编写的客户端SDK库，为了让团队主力语言Golang能够顺利接入SDK，因此使用了CGO桥接技术将C++11编写的SDK库封装成生产环境可用的Golang SDK，在翻阅了网上大部分关于cgo的中英文资料后，发现其中尤其是实现Go调用CPP库还是有非常多需要注意的细节，大部分中文资料都是以简单的C++的STL库函数封装为例点到为止，本文在前人基础之上总结了一系列封装复杂CPP库时的最佳实践的tips，希望能填补相关资料的空白。

如非必要，勿用CGO

将这一条列为第一条作为警示，因为许多cgo新手可能都会陷入执行效率上的误区，即：使用cgo调用而不是使用普通的Go函数会获得底层CPU单核执行性能上的大幅提升。这点其实需要具体情况具体分析，根据标准库中cgocall的源码来看，每个cgo的调用本质上都会有函数调用栈切换（传参，PC以及SP需要设置成外部的C程序）的过程，这些操作相比原生Go的调用来说都是额外的开销，在简单的计算函数调用上，cgo相比原生的运行效率单次调用的耗时可能相差能有上百倍。

// Call from Go to C.
func cgocall(fn, arg unsafe.Pointer) int32 {
    // ...
	// Reset traceback.
	mp.cgoCallers[0] = 0

	// 进入系统调用，这时go会新起一个系统线程M来执行后面的操作
	entersyscall()

	osPreemptExtEnter(mp)

	mp.incgo = true
	errno := asmcgocall(fn, arg)

	// ...
	osPreemptExtExit(mp)

	exitsyscall()

	// ...

	// 可能会有C到Go回调，相关的对象需要在GC上进行保活后再由GC决定是否能进行释放
	KeepAlive(fn)
	KeepAlive(arg)
	KeepAlive(mp)

	return errno
}

那么如何判断什么时候使用cgo呢？个人经验是看投入产出比，如果使用cgo能大大复用已有的C代码，降低后续的开发维护成本，亦或是CPU计算密集型的函数，使用C库对处理性能的提升能够很好地补偿cgo带来的副作用，那么cgo也是不错的选择。需要注意的是，如果一些第三方库已经使用纯Go和Plan9汇编达到到80～90%左右C库的运行性能时，也不推荐使用cgo的桥接库，尤其是当库的使用者需要在Go协程内大量并发调用库函数时，在用户态复用系统线程所带来的计算扩展性远比仅在C层执行略快的cgo调用进行内核上下文切换要有优势的多。

C ABI接口封装遵循最小化原则

如果我们要手工封装一个CPP库，实际执行的调用链为 Go runtime -> cgocall -> C ABI -> CPP func，ABI是应用二进制接口，只要符合这种二进制桥接接口的规范和约定，就能够很好的实现外部语言调用C接口。因此在实现桥接接口前建议先从Go层开始定义好符合Go语言语义的结构体和方法，再将Go对象映射到对应的C结构体或CPP对象，Go方法映射到对应的C函数和CPP方法，从而确定桥接的C库头文件，确定了中间桥接层的函数签名后，再着手使用C++语言实现头文件具体的逻辑，最终将CPP的实现和C的头文件编译链接在一起形成一个整体，这也是go能够调用cpp的底层逻辑。

不要使用SWIG生成C桥接代码

不想手工维护C接口，因此会有人会想到在python调用C++ so库的常用套路，那就是使用SWIG自动生成CPP库的stub函数，在前期我们准备编写桥接代码时其实也有类似的想法，不过最终还是放弃了，一个很重要的原因是swig的Go生成器在社区维护的热度并不高且很多C++11语法特性都是不支持的，比如智能指针等。而且生成的大量桥接代码都是不可读的，反而增加了后期维护和问题排查的心智负担，还可能会有内存泄露的风险，因此在生产环境下还是建议手工进行封装。

Batching your call

既然每次cgo调用都会有一定额外的开销，那么这种调用开销就会与调用次数成一个线性的关系，一种很自然的优化办法就是将多个cgo调用合并为一个，从而在处理同样多内容下减少降低cgo调用的额外开销，调用N次变为1次后，在一定周期内调用本身的额外的开销就近似变为原来的N分之一，在频繁调用的时候能够有效降低整体的调用时延。比如我封装的CPP调用内部涉及大量的大段字符串处理解析压缩序列化等操作，因此每次传递8M的大字符切片的处理时间通常来说就会比每次1M调用8次的整体处理时延要更低。

减少不必要的数据拷贝

cgo默认提供了一些常见的帮助函数来将Go中的内置类型转换成C中相对应的数据类型，在内部保证传入参数只读的情况下往往能做一些zero copy的tricks

例如传入只读的byte切片但是避免进行数据拷贝

b := buf.Bytes()
rc := C.the_function((*C.char)(&b[0]), C.int(buf.Len()))

实际等效于

str := buf.String()
p := C.CString(str)
defer C.free(p)
rc = C.the_function(p, C.int(len(str)))

第一种方式显然在大切片下避免了拷贝带来的额外开销

小心内存泄露

跨语言调用时拷贝传参通常来说都是比较安全的做法。不过当带垃圾回收的Go语言和手动管理内存的C语言再加上RAII的CPP相互混用时，一定要注意防止C或CPP层的堆内存泄露，Go调用C接口一般遵循谁申请，谁就负责释放的原则。

比如Go申请了一个C的堆内存给char*并将string变量的内容拷贝至C对应char*的内存空间中，那么就要由Go层来主动进行内存的释放。

package main

/*
#include <stdlib.h>
*/
import "C"

import "unsafe"

func HelloWorld() error {
    cs := C.CString("Hello World!")
    defer C.free(unsafe.Pointer(cs)) // 由Go层负责显式地调用C中的free进行释放

    // 安全地使用cs进行cgo调用
    // ...
    // 桥接层内部无需关心参数的释放
    err := C.my_c_func(cs)
    if err != nil {
		// 不为空的C字符串返回值由接收者释放
        defer C.free(unsafe.Pointer(err))
		return errors.New(C.GoString(err))
    }
	return nil
}

以此类推，在层层递进向下传参的时候，要保证接收者无需关心入参内存的释放，从而避免遗漏或者重复释放导致整个程序coredump。

需要注意的是在向上返回结果时是相反的，调用的返回者负责申请内存，而接收者负责主动释放内存。

正确处理智能指针

在许多的CPP库中，尤其是使用C++11编写的库，会使用大量的智能指针特性。很多的第三方库在创建对象的时候都会习惯性地将new出来的对象指针包一层shared_ptr用于自动引用计数，以便在对象脱离其作用域后能够正确的调用析构函数进行自动销毁并释放底层堆内存。但在cgo中智能指针的引用计数几乎毫无用武之地，因为在CPP层面无法感知Go层的引用情况，更别指望说能够正确地计数并自动销毁对象了。因此，如果想要在Go结构体持有CPP对象的情况下正确的释放对象资源，最好的办法就是将智能指针的引用计数在Go层中实现，最后由Go层来主动进行对象的释放。

如果CPP对象与Go对象是一一映射的话，我们就能够在应用层优雅地实现上层无感知的CPP对象引用计数。因为持有CPP对象裸指针的Go对象的引用数就等于CPP对象的引用数，这时 runtime.SetFinalizer 就完美地派上用场了，它相当于是Go对象被GC时会进行回调的钩子函数，利用这个钩子我们能轻松实现Go对象释放的同时安全地释放其底层持有的CPP对象。

package myClient

/*
#include <stdlib.h>

extern "C" {

void* client_create(const char* a); // 在CPP层调用构造函数new出对象指针返回给上层
void client_release(void* obj); // 在CPP层调用delete释放对象

}
*/
import "C"
import (
	"errors"
	"unsafe"
)

type Client struct {
	_ptr unsafe.Pointer
}

func New(a string) *Client {
	_a := C.CString(a)
	defer C.free(unsafe.Pointer(_a))

	_ptr := C.client_create(_a)

	cli := &Client{
		_ptr: _ptr
	}

	runtime.SetFinalizer(cli, func(c *Client) {
		// 保证Client对象在GC时自动将CPP对象进行销毁
		c.free()
	})

	return cli
}

func (c *Client) free() {
	C.client_release(c._ptr);
}

需要注意的是C语言中是没有类和对象这种语义的，因此为了保证ABI的兼容性在桥接的时候需要统一使用void*这种万能指针定义头文件，只有在.cpp实现时才能将其强转为对应的C++对象指针并进一步使用。

善用异常提高代码鲁棒性

底层实现是使用的C++语言，因此我们能在调用时使用try-catch语句包装一层将异常捕获并进行异常处理，无法处理也能将错误信息返回给上层调用方。

func (c *Client) DoSomething() error {
	err := C.do_something(c._ptr);
	if err != nil {
        defer C.free(unsafe.Pointer(err))
		return errors.New(C.GoString(err))
	}

	return nil
}

#include <string.h>

#define CAST_T(_T) reinterpret_cast<_T>

const char* do_something(void* obj) {
	try {
		CAST_T(CppClient*)(obj)->Do();
	}
	catch(MyException &e)
	{
		// handle failure
		// ...
		return NULL;
	}
	catch(const exception& e)
	{
		return strdup(e.what());
	}

	return NULL;
}

CGO编译工程化

通常我们CPP的SDK是在另外一个代码库进行维护的，因此cgo编译所依赖的静态库和动态库会在CPP库中的一个单独分支进行维护，这样保证了主库的升级不影响维护cgo的桥接cpp代码，同时也能轻松获取主库后续的更新。

Go sdk包的大致目录结构如下

➜  myclient tree -h
[]  .
├── []  lib
├── []  client.go
├── []  client_mock.go
└── []  wrapper.h

比如封装的go sdk包名为myclient，go层相关的对象和cgo调用的封装都会实现在 client.go 文件中，用于桥接的C ABI头文件定义一般会放在 wrapper.h 中，lib 目录用于存放编译链接 wrapper.h 头文件所需要的依赖，包括静态库以及相关的动态库。依赖由编译CPP库的特定分支得到并事先拷贝到目录中。整个工程目录也看起来会比较清晰自然，wrapper.h 的CPP实现我们选择在原始CPP库中的分支中维护，相当于通过C定义的接口彻底解耦服务调用方和服务提供方。

而 client_mock.go 用于条件编译适配在本地mac环境的编译调试，因为引入cgo有可能会破坏跨平台编译调试的便利性，使用条件编译能一定程度上解决平台隔阂导致整个二进制程序无法编译的问题。

调试以及pprof调优

这点可能是许多使用cgo的人吐槽最多的点，目前也没有一个比较好用的debug cgo程序的办法，prof cpu的话使用 perf 生成火焰图还是能分析的，GCC编译时使用低优化等级是能够保留具体调用堆栈信息的。

如果cgo调用内出现内存泄露，那就比较麻烦了。对于cgo程序debug或者是内存分析我自己是没有找到比较好的办法，也欢迎大家建言献策。

实际踩过的坑

在使用封装好的go sdk在生产环境实际运行的时候，我们发现所有核的CPU有异常打满的情况，通过go的cpu pprof最终锁定到唯一一个重计算的cgo调用上，上层大约会有持续上百个协程在并发调用。

go func() {
	C.heavy_process_func()
}

但是实际使用perf top命令分析进程cpu的时候，我们发现占用CPU时间最多的操作竟然是内核层的_raw_spin_lock，而在heavy_process_func的全过程中我们的业务逻辑中并没有任何使用自旋锁的痕迹，且调用上层的协程之间也毫无交集，何来的竞态抢互斥锁？

最终通过主动输出CPP层的所有异常日志，真相才得以浮出水面：原来C++在多线程各自并发抛大量异常时，执行栈展开会在glibc中抢全局锁。因此，在将异常正确收敛后，问题才最终解决。新版本的glibc中已经修复了多线程抛异常抢全局锁的这个问题，详情可以见对应的issue和patch。

Bug - Concurrently throwing exceptions is not scalable

参考资料

用Go STL查询DB引发的内存泄露

Fri, 06 Mar 2020 13:54:12 +0800

问题起因

这几天有一个 Go API service 经过定时监控发现占用的内存不断上涨，内存从初始的 70M 一直上升到超过 1G 直到吃光内存退出，基本上就可以断定是存在内存泄露的问题了，但是因为自带垃圾回收的语言出现内存泄露的情况较少，如果存在那一定是大问题，因此有了下文详细的排查过程，为日后处理此类问题积累经验。

分析排查

goroutine泄露

之前就有听说过一句名言：Go 中的内存泄露十有八九都是 goroutine 协程泄露，是否真的如此呢？对 runtime.NumGoroutine() 的定时查询可以帮助我们进行判断，或者线上开启了 pprof 的话访问 /debug/pprof 就可以看到 goroutine 的数量，我使用了 expvar 来定时暴露协程的总数信息，在本地对线上数据定时进行抓取。

// server.go
// 将统计数据通过 expvar.Handler 暴露到 HTTP 服务中
mux := http.NewServeMux()
mux.Handle("/debug/vars", expvar.Handler())


// main.go
func sampleInterval() chan struct{} {
	done := make(chan struct{})
	go func() {
		ticker := time.NewTicker(1 * time.Second)
		numG := expvar.NewInt("runtime.goroutines")
		defer ticker.Stop()

		for {
			select {
			case <-ticker.C:
				numG.Set(int64(runtime.NumGoroutine()))
			case <-done:
				return
			}
		}
	}()
	return done
}

// 本地运行
// curl http://host:port/debug/vars
{
	"runtime.goroutines": 48
}

done chan 会被返回，以便我们关闭系统时可以进行优雅退出。通过一段时间的抓取和图表分析，发现并不是 goroutine 的泄露，如果是，那么可以访问 /debug/pprof/goroutine?debug=1 在线上查看每个 G 的状态，然后再来做进一步的分析，但显然通过排除法，这不是这次事故的问题所在。

长期持有引用

那么新的问题也就很自然地浮现出来：如果 G 的数量有上升然后总是能够自动回落，说明非常驻型的 G 都能够正常运行结束，G的阻塞等待导致迟迟无法退出造成的泄露是可以排除了，那么我们是否能够认为内存的泄露就完全与 G 无关了？答案是不能，因为我们不能确定 G 是否会导致我们的一些引用对象被一直持有，在标记 Mark 阶段的时候这些依然被持有的对象肯定是不能被垃圾回收的，但它因为某些原因一直被持有而且还伴随着新的内存分配，这是导致内存不断上涨的第二大元凶。

所以，随着问题落到了对象或者是对象群的内存分配上了，这个问题可以是某个大的 slice 一直不断添加元素却一直在对象的生命周期中被引用，也可以是某对象中持有其他对象的指针，类似链表状的引用关系，如果这个引用链不断增长，那么同样也会造成内存的泄露。

使用 pprof 采样分析堆内存

通过获取 pprof heap profile，我们能够在线上直接生成当前堆内存分配的快照文件并通过 .pb.gz 压缩包的形式持久化到本地供我们作进一步的离线分析。

go tool pprof http://[domain]/debug/pprof/heap

使用命令行就能够将堆内存的快照以及各种统计数据都持久化到本地进行分析，进入到 pprof 交互式命令行。这边我直接在线上隔一段时间分别抓取了两次快照到本地来分析：

File: binary
Type: inuse_space
Time: Feb 27, 2020 at 12:06pm (CST)
(pprof) top
Showing nodes accounting for 44174.92kB, 93.50% of 47247.81kB total
Showing top 10 nodes out of 114
      flat  flat%   sum%        cum   cum%
35842.64kB 75.86% 75.86% 35842.64kB 75.86%  myfuncA
 1825.78kB  3.86% 79.73%  1825.78kB  3.86%  github.com/mozillazg/go-pinyin.init
 1805.17kB  3.82% 83.55%  2354.01kB  4.98%  compress/flate.NewWriter
 1024.14kB  2.17% 85.71%  2048.25kB  4.34%  database/sql.(*DB).prepareDC
 1024.08kB  2.17% 87.88%  1024.08kB  2.17%  net.(*file).getLineFromData
  561.50kB  1.19% 89.07%   561.50kB  1.19%  html.populateMaps
  548.84kB  1.16% 90.23%   548.84kB  1.16%  compress/flate.(*compressor).initDeflate
  516.76kB  1.09% 91.32%   516.76kB  1.09%  net/http.(*http2Framer).WriteDataPadded
  513.31kB  1.09% 92.41%   513.31kB  1.09%  regexp.onePassCopy
  512.69kB  1.09% 93.50%   512.69kB  1.09%  vendor/golang.org/x/net/http2/hpack.(*headerFieldTable).addEntry

File: binary
Type: inuse_space
Time: Feb 27, 2020 at 5:58pm (CST)
(pprof) top
Showing nodes accounting for 80.65MB, 83.62% of 96.45MB total
Showing top 10 nodes out of 145
      flat  flat%   sum%        cum   cum%
      35MB 36.29% 36.29%       35MB 36.29%  myfuncA
    8.50MB  8.81% 45.10%       11MB 11.41%  github.com/lib/pq.parseStatementRowDescribe
    7.05MB  7.31% 52.42%     7.05MB  7.31%  database/sql.(*DB).addDepLocked
       6MB  6.22% 58.64%        6MB  6.22%  encoding/json.(*decodeState).literalStore
       5MB  5.18% 63.82%    19.50MB 20.22%  github.com/lib/pq.(*conn).prepareTo
    4.59MB  4.76% 68.58%     4.59MB  4.76%  reflect.unsafe_NewArray
    4.50MB  4.67% 73.25%       11MB 11.41%  queryfuncB
       4MB  4.15% 77.40%    18.56MB 19.24%  database/sql.(*DB).prepareDC
    3.50MB  3.63% 81.03%     3.50MB  3.63%  github.com/lib/pq.decideColumnFormats

使用 top 可以查看持有内存最多的几个函数并进行排序，通过比对持有最多内存的函数，发现尽管 myfuncA 持有了很多内存，但是两个时间点的 myfuncA 产生的内存都没有变化，而总的内存占用从 47M 上升到了 96M，因此可以排除 myfuncA 泄露的嫌疑。但值得注意的是，这段时间多出来的 50M 也不全是因为内存的泄露，DB 查询时的反序列化也需要申请较多内存，根据 Go runtime 内存分配的策略，GC 并不会立即回收这些内存，即便回收也不会很快将闲置的内存归还给OS，在一段时间内这些内存依然会存在于内存分配器的多级内存池中。因此这其中依然存在着一些阻碍我们分析的干扰项。顺带提一下 reflect.unsafe_NewArray 这个函数，之前看到有人在怀疑它会导致内存泄露，事实上只要是 json 反序列化一个 slice 都会使用它来申请内存，它的上层是 reflect.MakeSlice ，可以根据反射得到的 type 类型信息来创建 slice ，可以理解为通用 slice 的构造函数。

对比两个快照之间的差异

仅仅是通过肉眼查看两个快照之间的差异还是存在蛮多的干扰的，如果能够以第一个时间点为基准看与第二个时间点 diff 过后的结果可能会更加清晰一些。

go tool pprof -base pprof.binary.alloc_objects.alloc_space.inuse_objects.inuse_space.001.pb.gz pprof.binary.alloc_objects.alloc_space.inuse_objects.inuse_space.002.pb.gz

File: binary
Type: inuse_space
Time: Feb 27, 2020 at 12:06pm (CST)
(pprof) top
Showing nodes accounting for 37.65MB, 76.19% of 49.42MB total
Dropped 1 node (cum <= 0.25MB)
Showing top 10 nodes out of 118
      flat  flat%   sum%        cum   cum%
    6.50MB 13.16% 13.16%        9MB 18.21%  github.com/lib/pq.parseStatementRowDescribe
    5.05MB 10.23% 23.38%     5.05MB 10.23%  database/sql.(*DB).addDepLocked
       5MB 10.12% 33.50%        5MB 10.12%  encoding/json.(*decodeState).literalStore
    4.58MB  9.28% 42.78%     4.58MB  9.28%  reflect.unsafe_NewArray
       4MB  8.10% 50.87%        8MB 16.19%  funcB (callByA)
       4MB  8.10% 58.97%       16MB 32.38%  github.com/lib/pq.(*conn).prepareTo
       3MB  6.07% 65.04%        3MB  6.07%  github.com/lib/pq.decideColumnFormats
    2.50MB  5.06% 70.10%     2.50MB  5.06%  github.com/lib/pq.(*readBuf).string
    1.51MB  3.05% 73.15%     1.51MB  3.05%  github.com/lib/pq.textDecode
    1.50MB  3.04% 76.19%    39.10MB 79.12%  ctrlfuncA

通过 -base 指定基准，再次使用 top 可以准确地列出这多出来的 50M 究竟是何人所为。把这些列出来的方法进行简单的分类：funcA是控制器函数，而 funcB 是 M 层的方法，被A调用并与 postgresql 直接打交道获取数据，其余的有反序列化含有 json 数据字段的标准库函数，最后还有一些与数据库连接相关的函数。初步可以确定的是，内存泄露一定存在于这个方法调用链中的某一步。

在交互式命令行通过 list 方法名 可以一步步深入分析方法调用链上具体的占用情况，排除掉反序列化对象分配内存的干扰，并结合快照2的占用情况。定位到 *DB 和 *conn 这两个对象上，方法调用定位到 sqlx 提供的 Preparex 方法以及 Preparex 产生的 Stmt 对象的 Get 方法。

func (r repoXXX) FindByID(id string) (*T, err) {
	stmt, err := r.Preparex(`MY SQL QUERY`) // ???
	if err != nil {
		return nil, err
	}

	t := new(T)
	err = stmt.Get(t, id) // ???
	if err != nil {
		if err == sql.ErrNoRows {
			return nil, errno.TorNotFound
		}
		return nil, err
	}
	return t, nil
}

找到元凶

sqlx 只是 database/sql 的简单包装库，要想知道找到的这两个方法究竟做了些什么，还得从 database/sql 开始说起。

DB 创建

func Open(driverName, dataSourceName string) (*DB, error) {
	// 检查数据库驱动是否已经初始化
	driversMu.RLock()
	driveri, ok := drivers[driverName]
	driversMu.RUnlock()
	// 没有初始化，报错
	if !ok {
		return nil, fmt.Errorf("sql: unknown driver %q (forgotten import?)", driverName)
	}

	if driverCtx, ok := driveri.(driver.DriverContext); ok {
		// 通过URI传入连接数据库的配置信息
		connector, err := driverCtx.OpenConnector(dataSourceName)
		if err != nil {
			return nil, err
		}
		// 初始化 DB 对象并返回
		return OpenDB(connector), nil
	}

	// 默认 connector
	return OpenDB(dsnConnector{dsn: dataSourceName, driver: driveri}), nil
}

OpenDB() 显然是 DB 的构造函数，继续往下看

func OpenDB(c driver.Connector) *DB {
	ctx, cancel := context.WithCancel(context.Background())
	db := &DB{
		connector:    c,
		openerCh:     make(chan struct{}, connectionRequestQueueSize),
		resetterCh:   make(chan *driverConn, 50),
		lastPut:      make(map[*driverConn]string),
		connRequests: make(map[uint64]chan connRequest),
		stop:         cancel,
	}

	go db.connectionOpener(ctx)
	go db.connectionResetter(ctx)

	return db
}

几个关键的组成部分： openerCh 用于缓存创建新连接的请求，表意单一并且符合先进先出的逻辑，定义成chan struct 再好不过了

resetterCh 用于异步重置连接的 context 并返回当前连接执行 query 的 error

使用了两个 G 异步执行上述的两个操作

lastPut 用于 debug ，跳过

connRequests 用于无闲置数据库连接且无法再创建新连接时的异步请求排队，key是递增的，value 使用 chan 防止读取阻塞，len可以非常方便地计数

func (db *DB) putConnDBLocked(dc *driverConn, err error) bool {
	// ...
	// 发现有请求在排队
	if c := len(db.connRequests); c > 0 {
		var req chan connRequest
		var reqKey uint64
		for reqKey, req = range db.connRequests {
			break
		}
		delete(db.connRequests, reqKey) // 排队队列中取出=
		if err == nil {
			dc.inUse = true
		}
		// 为这个请求分配连接
		req <- connRequest{
			conn: dc, // *driverConn 即数据库连接
			err:  err,
		}
		return true
	}

}

目前我们可以得知， connRequest 代表创建新连接的请求，connRequests 用于全局的请求排队，每当有创建新连接的请求时，DB 会尝试重用可用的 driverConn以满足这些请求，注意这些请求不是 query 请求，而是创建连接的请求

记录资源的依赖引用

DB对象的 conn 方法负责获取连接，有连接了，才能将我们的语句发送到数据库，以 SELECT 语句的查询为例

func (db *DB) query(ctx context.Context, query string, args []interface{}, strategy connReuseStrategy) (*Rows, error) {
	// 获取连接或者失败返回错误
	dc, err := db.conn(ctx, strategy)
	if err != nil {
		return nil, err
	}

	// 熟悉的 stmt, Rows 对象是从这里创建，绑定driverConn执行然后被返回的
	return db.queryDC(ctx, nil, dc, dc.releaseConn, query, args)
}

先不要跑太远，毕竟我们并不是使用这种方法访问数据库，但是上面的调用可以帮助理清标准库是如何组织这些底层对象的。现在回到 sqlx 的 preparex 方法，这里是我们问题的开始，最终调用的还是标准库 DB 的 PrepareContext 方法

func (db *DB) PrepareContext(ctx context.Context, query string) (*Stmt, error) {
	var stmt *Stmt
	var err error
	// 约定一个失败重试次数，使用标志位控制获取连接的策略（优先使用缓存的连接）
	for i := 0; i < maxBadConnRetries; i++ {
		stmt, err = db.prepare(ctx, query, cachedOrNewConn)
		if err != driver.ErrBadConn {
			break
		}
	}
	if err == driver.ErrBadConn {
		return db.prepare(ctx, query, alwaysNewConn)
	}
	return stmt, err
}

func (db *DB) prepare(ctx context.Context, query string, strategy connReuseStrategy) (*Stmt, error) {
	// 同样尝试获取连接或者失败返回
	dc, err := db.conn(ctx, strategy)
	if err != nil {
		return nil, err
	}
	return db.prepareDC(ctx, dc, dc.releaseConn, nil, query)
}

这里的 prepare 和前面提到的 query 方法非常相似，后面我们再详谈它们的区别，这里我们接着 prepareDC 这条线索继续往下探索。

// cg 为 nil 表示启用连接池！（手动画重点）
func (db *DB) prepareDC(ctx context.Context, dc *driverConn, release func(error), cg stmtConnGrabber, query string) (*Stmt, error) {
	var ds *driverStmt
	var err error
	defer func() {
		release(err)
	}()
	withLock(dc, func() {
		ds, err = dc.prepareLocked(ctx, cg, query)
	})
	if err != nil {
		return nil, err
	}
	stmt := &Stmt{
		db:    db,
		query: query,
		cg:    cg,
		cgds:  ds,
	}

	// 这部分才是 preparex 的真实目的，使用连接池
	if cg == nil {
		// prepare 事先将得到的连接和语句保存起来
		stmt.css = []connStmt{{dc, ds}}
		// 记录当前已关闭连接的总数，清理已关闭的连接时会用到
		stmt.lastNumClosed = atomic.LoadUint64(&db.numClosed)
		// 添加依赖引用计数（目前来看不太清楚是干什么用），但是stmt肯定被持有
		db.addDep(stmt, stmt)
	}
	return stmt, nil
}

其中返回的 stmt 就是 Preparex 的所得产物，然后执行了 Get，经过 sqlx 的包装，最终调用的还是标准库中的func (s *Stmt) QueryContext，和 sqlx 中的 func (r *Row) scanAny

可以肯定的是，在调用 Preparex 后，stmt 引用已经被 db 持有，只要 db 对象一直存在，stmt 想要被释放，就必须有对应的代码手动解除 stmt 的引用，简要的看看 QueryContext，是否有我们想要的类似 removeDep 的操作

func (s *Stmt) QueryContext(ctx context.Context, args ...interface{}) (*Rows, error) {
	// ...
	rowsi, err = rowsiFromStatement(ctx, dc.ci, ds, args...)
	if err == nil {
		rows := &Rows{
			dc:    dc,
			rowsi: rowsi,
		}
		s.db.addDep(s, rows) // HERE

		rows.releaseConn = func(err error) {
			releaseConn(err)
			s.db.removeDep(s, rows) // HERE
		}
		var txctx context.Context
		if s.cg != nil {
			txctx = s.cg.txCtx()
		}
		rows.initContextClose(ctx, txctx)
		return rows, nil
	}

	releaseConn(err)
}

有，但这些是关于 rows 的引用记录以及数据库连接的重用的代码，并没有看到 stmt 对象的释放，同样翻看 sqlx 的 scanAny，主要是将数据库返回的数据通过调用 Scan 序列化到传入 Get 的结构体具体字段中。

上述发现证实了本次内存泄露的元凶：db.dep，即用于引用计数从而保证依赖先行释放的字典，这个字典保证了只有元素的依赖被释放后当前元素才能释放，调用当前元素的 finalClose 方法自行释放当前元素持有的资源。

解决泄露

因此想要解决这次的内存泄露，就必须让 dep 放弃对 stmt 的引用。通过对 sql.go 文件的简单搜索，stmt 对象的释放就藏在它的 close 方法中。

func (s *Stmt) Close() error {
	// ...
	if s.cg == nil {
		return s.db.removeDep(s, s) // 真正释放了stmt，不再持有其引用
	}
}

一行代码就能解决了

stmt, _ := r.Preparex(`MY SQL QUERY`)
// 这句必不可少！！
defer stmt.Close()
// ...

重新部署，并对内存使用情况进行采样，结果如下图所示：

GC 能够正常地回收 stmt 对象，问题解决！

总结

得到的教训：

前期：做 load test，能在线下解决就别放到线上；善用 pprof；写好文档，避免他人踩坑
上线：监控和报警要做到位，内存占用超过了一定阈值必须引起重视，善用 http/pprof
平时：多熟悉平时重度使用的包和标准库，尤其是标准库，其中隐藏了很多的细节，稍不留神就踩坑

其他潜在的泄露（彩蛋）

说实话，这并不是我在 Go 中遇到的第一次内存泄露，但 Go 确实没那么容易出现这类问题，通过我的多次踩坑反思，我发现一些 G 导致的内存泄露其实通过 pprof 或者监控是能够很快得到解决的，反而是长期被持有的引用很容易被忽视掉，这些泄露的苗头常常会出现在：

手动维护的对象池
手动控制的系统资源：如定时器，连接，IO缓冲流等
默认无上限的数值限制：如db.maxOpen

理解 CPU Cache 对并发性能的影响

Mon, 30 Dec 2019 10:42:32 +0800

一般来说每个 CPU 核有 L1 和 L2 缓存，L3是共享缓存以缓存行为单位存储，通常是 64 字节为一行

这种利用局部性原理的缓存是数组访问比链表访问快的主要原因

伪共享问题 false sharing

如果两个核都有同一个缓存行，但是它们操作的却是缓存行中的不同变量，这时就会出现伪共享问题，处理器会用标志标记缓存行的修改状态，需要通过 MESI 协议通信来传输被修改的缓存行。表面上看这两个变量是在不同的 L1 中被独立修改的，但事实上它们都共享 L3 上的同一个缓存行，其中会存在大量的数据同步的通信开销

通信获取缓存的先决条件：

线程的工作从一个核换到另一个核（联系GPM模型中的被绑定的M，这也是为什么最好是由原来绑定的M来运行G的重要原因，利用处理器局部缓存！）
两个不同的核需要处理相同的缓存行

解决伪共享问题

案例：当多个线程需要处理多个相邻的数据项的时候？如：并发地修改数组，结构体里相邻的字段存在被并发读取修改的情况等

其中一个可行的办法就是进行边界填充，在 Go 中通常情况下可以使用匿名下划线的 []byte 进行填充，让这些受影响的数据项位于不同的 cache line 即可，这样就能够打破共享从而避免数据同步通信的开销

Go常见并发模式

Sun, 22 Sep 2019 10:08:00 +0000

Go语言的并发模式是其最具特色的编程范式之一。本文总结了在Go开发中最常见的几种并发模式，包括请求-接收模式、单一状态者模式、生产-消费模式、Pipeline流水线模式等。这些模式能够帮助我们更好地组织和管理goroutine，使并发程序更加健壮和优雅。通过这些模式的学习，你将能够更好地掌握Go语言的并发特性，写出更高质量的并发代码。

极简的请求-接收模式

// 请求函数根据参数返回接收器
func Glob(pattern string) <-chan Item {
	c := make(chan Item)	// 1.初始化接收器

	// 2.匿名 G 闭包执行程序
	go func() {
		defer close(c)
		for name, item := range items {
			if ok, _ := filepath.Match(pattern, name); !ok {
				continue
			}
			c <- item
		}
	}()

	// 3. 快速返回接收器以便后面的程序从chan中读
	return c
}

func main() {
	for item := range Glob("[ab]*") {
		fmt.Println(item)
	}
}

单一状态者

一个 G 持有一个全局的状态，其他的 G 可以通过 chan 访问到 G 持有的状态

reads := make(chan *readOp)
writes := make(chan *writeOp)

// 状态持有者
go func() {
    var state = make(map[int]int)
    for {
        select {
        case read := <-reads:
			// 返回结果
            read.resp <- state[read.key]
        case write := <-writes:
            state[write.key] = write.val
			// 返回结果
            write.resp <- true
        }
    }
}()

// 请求者
go func() {
    for {
        read := &readOp{
            key:  rand.Intn(5),
            resp: make(chan int)}
        reads <- read
        <-read.resp
     }
}()

go func() {
    for {
        write := &writeOp{
            key:  rand.Intn(5),
            val:  rand.Intn(100),
            resp: make(chan bool)}
        writes <- write
        <-write.resp
     }
}()

先生产，后消费

// 先生产，已知生产个数
chanOwner := func() <-chan int {
    results := make(chan int, 5)
    go func() {
        defer close(results)
        for i := 0; i <= 5; i++ {
            results <- i
        }
    }()
    return results
}

consumer := func(results <-chan int) {
    for result := range results {
        fmt.Printf("Received: %d\n", result)
    }
    fmt.Println("Done receiving!")
}

results := chanOwner()
// 消费
consumer(results)

消费者通知生产者

newRandStream := func(done <-chan interface{}) <-chan int {
    randStream := make(chan int)
    go func() {
        defer fmt.Println("newRandStream closure exited.")
        defer close(randStream)
        for {
            select {
            case randStream <- rand.Int():
            case <-done:
				// 停止生产，退出
                return
            }
        }
    }()

    return randStream
}

done := make(chan interface{})
randStream := newRandStream(done)
fmt.Println("3 random ints:")
for i := 1; i <= 3; i++ {
    fmt.Printf("%d: %d\n", i, <-randStream)
}
// 消费者主动要求生产停止
close(done)

多 channel 合并使得安全退出（OR channel）

var or func(channels ...<-chan interface{}) <-chan interface{}
or = func(channels ...<-chan interface{}) <-chan interface{} { 1
    switch len(channels) {
    case 0: 2
        return nil
    case 1: 3
        return channels[0]
    }

    orDone := make(chan interface{})
    go func() {
        defer close(orDone)

        switch len(channels) {
        case 2:
            select {
            case <-channels[0]:
            case <-channels[1]:
            }
        default:
            select {
            case <-channels[0]:
            case <-channels[1]:
            case <-channels[2]:
            case <-or(append(channels[3:], orDone)...):
            }
        }
    }()
    return orDone
}

sig := func(after time.Duration) <-chan interface{}{
    c := make(chan interface{})
    go func() {
        defer close(c)
        time.Sleep(after)
    }()
    return c
}

start := time.Now()
<-or(
    sig(2*time.Hour),
    sig(5*time.Minute),
    sig(1*time.Second),
    sig(1*time.Hour),
    sig(1*time.Minute),
)
fmt.Printf("done after %v", time.Since(start))

只要有其中一个 chan 退出，其他的 chan 都退出

当需要将某一函数并发执行时，可以一律将返回值打包成结构体使用 chan 传递

例如：并发 http.Get

// 把返回值统一成 result 结构体
type Result struct {
    Error error
    Response *http.Response
}

checkStatus := func(done <-chan interface{}, urls ...string) <-chan Result {
    results := make(chan Result)
    go func() {
        defer close(results)

        for _, url := range urls {
            var result Result
            resp, err := http.Get(url)
            result = Result{Error: err, Response: resp}
            select {
            case <-done:
                return
            case results <- result:
            }
        }
    }()
    return results
}

done := make(chan interface{})
defer close(done)

urls := []string{"https://www.google.com", "https://badhost"}
for result := range checkStatus(done, urls...) {
    if result.Error != nil {
        fmt.Printf("error: %v", result.Error)
        continue
    }
    fmt.Printf("Response: %v\n", result.Response.Status)
}

同时，这个模式也启发我们在容错方面可以引入一个程序状态的观察者，它能够同时控制程序的走向，在上述例子中，我们默认那个观察者是 main

错误控制

done := make(chan interface{})
defer close(done)

errCount := 0
urls := []string{"a", "https://www.google.com", "b", "c", "d"}
for result := range checkStatus(done, urls...) {
    if result.Error != nil {
        fmt.Printf("error: %v\n", result.Error)
        errCount++
        if errCount >= 3 {
			// 当错误过多的时候，跳出并终止请求 G
            fmt.Println("Too many errors, breaking!")
            break
        }
        continue
    }
    fmt.Printf("Response: %v\n", result.Response.Status)
}

流水线 Pipeline 模式

将生产过程进行拆分，解耦，多个 G 之间互相协同，但每个 G 之间又相互独立能进行拆分的前提：不同的阶段处理的都是同一类型的数据

generator := func(done <-chan interface{}, integers ...int) <-chan int {
    intStream := make(chan int)
    go func() {
        defer close(intStream)
        for _, i := range integers {
            select {
            case <-done:
                return
            case intStream <- i:
            }
        }
    }()
    return intStream
}

multiply := func(
  done <-chan interface{},
  intStream <-chan int,
  multiplier int,
) <-chan int {
    multipliedStream := make(chan int)
    go func() {
        defer close(multipliedStream)
        for i := range intStream {
            select {
            case <-done:
                return
            case multipliedStream <- i*multiplier:
            }
        }
    }()
    return multipliedStream
}

add := func(
  done <-chan interface{},
  intStream <-chan int,
  additive int,
) <-chan int {
    addedStream := make(chan int)
    go func() {
        defer close(addedStream)
        for i := range intStream {
            select {
            case <-done:
                return
            case addedStream <- i+additive:
            }
        }
    }()
    return addedStream
}

// 每个阶段都可以使用 done channel 安全退出 goroutine
done := make(chan interface{})
defer close(done)

// 每个阶段都返回要处理的数据类型的 channel
intStream := generator(done, 1, 2, 3, 4)
pipeline := multiply(done, add(done, multiply(done, intStream, 2), 1), 2)

for v := range pipeline {
    fmt.Println(v)
}

多个 goroutine 通过多个同类型的 channel 和共享一个 done channel 联系在一起

生成器模式

无限重复生成

repeat := func(
    done <-chan interface{},
    values ...interface{},
) <-chan interface{} {
    valueStream := make(chan interface{})
    go func() {
        defer close(valueStream)
		// 死循环不断重复发送 slice 的内容直到发送信号停止
        for {
            for _, v := range values {
                select {
                case <-done:
                    return
                case valueStream <- v:
                }
            }
        }
    }()
    return valueStream
}

上述模式可以产生一个生成流,下面我们来从这个流中读取

从流中按需读取

take := func(
    done <-chan interface{},
    valueStream <-chan interface{},
    num int,
) <-chan interface{} {
    takeStream := make(chan interface{})
    go func() {
        defer close(takeStream)
        for i := 0; i < num; i++ {
            select {
            case <-done:
                return
            case takeStream <- <- valueStream:
            }
        }
    }()
    return takeStream
}

done := make(chan interface{})
defer close(done)

// 从流中截取前 10 个元素然后退出
for num := range take(done, repeat(done, 1), 10) {
    fmt.Printf("%v ", num)
}

worker pool 协程池模式

worker := 8
c := make(chan int, l)

var wg sync.WaitGroup
wg.Add(worker)

for i:=0;i<worker;i++ {
	go func(){
		for row := range c {
			for col := range m.m[row] {
				fillPixel(m, row, col)
			}
		}
	}()
}

for row := range m.m {
	c <- row
}
close(c)

pub-sub 发布订阅模式

每一个订阅者都会持有一个 chan 每个订阅者会有一个过滤器来进行内容的过滤过滤器通常是一个 bool 函数值类型发布者使用 map 存储订阅者 chan 到过滤函数的映射每次发布的时候都遍历 map 然后使用对应的过滤器进行过滤后投递即可

事件驱动模式

常用于在一些操作执行的过程中触发其他操作例如通知这些事件的处理操作需要事先注册，然后在合适的时间触发

package events

import (
    "time"
)

var UserCreated userCreated

// 定义上下文荷载
type UserCreatedPayload struct {
    Email string
    Time  time.Time
}

// 带荷载上下文的函数链
type userCreated struct {
    handlers []interface{ Handle(UserCreatedPayload) }
}

// Register 将时间的处理函数添加进切片中
func (u *userCreated) Register(handler interface{ Handle(UserCreatedPayload) }) {
    u.handlers = append(u.handlers, handler)
}

// Trigger 依次触发 goroutine 来执行带上下文的处理函数
func (u userCreated) Trigger(payload UserCreatedPayload) {
    for _, handler := range u.handlers {
        go handler.Handle(payload)
    }
}

package main

import (
    "time"

    "github.com/stephenafamo/demo/events"
)

func init() {
    createNotifier := userCreatedNotifier{
        adminEmail: "the.boss@example.com",
        slackHook: "https://hooks.slack.com/services/...",
    }

	// 注册处理回调
    events.UserCreated.Register(createNotifier)
}

type userCreatedNotifier struct{
    adminEmail string
    slackHook string
}

func (u userCreatedNotifier) notifyAdmin(email string, time time.Time) {
    // ...
}

func (u userCreatedNotifier) sendToSlack(email string, time time.Time) {
    // ...
}

// 只要符合处理函数的签名就可以自定义处理函数的内部实现
func (u userCreatedNotifier) Handle(payload events.UserCreatedPayload) {
    // Do something with our payload
    u.notifyAdmin(payload.Email, payload.Time)
    u.sendToSlack(payload.Email, payload.Time)
}

触发事件处理函数

package auth

import (
    "time"

    "github.com/stephenafamo/demo/events"
    // Other imported packages
)

func CreateUser() {
    // ...
	// 解耦之后只需要传入需要的载荷即可，不用关心具体的处理逻辑
    events.UserCreated.Trigger(events.UserCreatedPayload{
        Email: "new.user@example.com",
        Time: time.Now(),
    })
    // ...
}

Leetcode 989. Add to Array-Form of Integer

Thu, 14 Feb 2019 00:00:00 +0000

题目描述

For a non-negative integer X, the array-form of X is an array of its digits in left to right order. For example, if X = 1231, then the array form is [1,2,3,1]

Given the array-form A of a non-negative integer X, return the array-form of the integer X+K.

// Author: Tecker
// date: 2019.2.14
// 132ms, 13.3MB beat 99.19%, 100.00%
// time: O(N), space: O(1) or O(len(K))
class Solution {
public:
    vector<int> addToArrayForm(vector<int>& A, int K) {
        // 如果 A 代表的数字比 K 小(K 最大10000)
        if (A.size()<5) {
            int t=1;
            int sum=0;
            for(int i=A.size()-1;i>=0;--i) {
                sum+=A[i]*t;
                t*=10;
            }
            // 直接转换相加，然后对 A 原地修改返回
            sum+=K;
            if (sum==0) return vector<int>{0};

            // 先向后插入低到高位再反转
            int pos=0;
            while(sum!=0) {
                if (pos>=A.size())
                    A.push_back(sum%10);
                else
                    A[pos]=sum%10;
                sum/=10;
                ++pos;
            }

            reverse(A.begin(), A.end());
            return A;
        }

        // 直接将 K 加到最低位，然后向最高位不断推进
        bool needMore = false;
        for(int i=A.size()-1;i>=0;--i) {
            A[i]+=K;
            if (A[i] < 10) break;
            if (i==0) needMore=true;
            K=A[i]/10;
            A[i]%=10;
        }

        if (!needMore) return A;

        // 前面要补1
        reverse(A.begin(), A.end());
        A.push_back(1);
        reverse(A.begin(), A.end());
        return A;
    }
};

收获

向 vector 头原地插入元素可以先反转从尾部添加再反转

Leetcode 985. Sum of Even Numbers After Queries

Wed, 13 Feb 2019 00:00:00 +0000

题目描述

时间复杂度：O(N)

空间复杂度：O(1)

// Author: Tecker
// 176ms, 28.7MB; beat 96.40%, 100%
class Solution {
public:
    vector<int> sumEvenAfterQueries(vector<int>& A, vector<vector<int> >& queries) {
        vector<int> res(A.size(), 0);
        int sum=0;
        A[queries[0][1]]+=queries[0][0];
        for(int &num : A) {
            if (num%2==0) sum+=num;
        }
        res[0]=sum;
        for(int i=1;i<queries.size();++i) {
            int val=queries[i][0];
            int idx=queries[i][1];
            int tmp = A[idx];
            A[idx]+=val;
            if (isEven(tmp)) {
                if (!isEven(A[idx]))
                    sum-=tmp;
                else
                    sum+=val;
            } else {
                if (isEven(A[idx])) sum+=A[idx];
            }
            res[i]=sum;
        }
        return res;
    }

private:
    inline bool isEven(int a) {
        return !(a & 1);
    }
};

刚开始本来是想要用取模来做的，结果一不小心踩了大坑，以后要注意负数取模的正确计算方式

int mod(int x, int m) {
    return (x%m + m)%m;
}

收获: 在不同的语言中，对负数执行取模运算，结果有可能会是不同的

poj 3616 Milking Time

Sun, 29 Jul 2018 00:00:00 +0000

原题地址

知识点：权值区间DP

解题报告

#include <cstdio>
#include <algorithm>
#include <iostream>
#include <vector>

using namespace std;

struct P {
  int start, end, e;
};

bool cmp(const P &a, const P &b) {
  return a.start < b.start;
}

int N, M, R;
struct P a[1002];
int dp[1002];

int main() {
  scanf("%d %d %d", &N, &M, &R);
  int i, j;
  for(i=0;i<M;i++) {
    struct P p;
    scanf("%d %d %d", &p.start, &p.end, &p.e);
    // 化成带权值的区间 DP
    p.end += R;
    a[i] = p;
  }

  sort(a, a+M, cmp);
  for(i=0;i<M;++i) {
    dp[i] = a[i].e;
    for(j=0;j<i;++j) {
      // 把当前时间段允许的之前的时间段都选一遍并取最大值
      if (a[j].end <= a[i].start) dp[i] = max(dp[i], dp[j]+a[i].e);
    }
  }

  cout << *max_element(dp, dp+M) << endl;
  return 0;
}

poj 2385 Apple Catching 0ms

Sat, 14 Jul 2018 00:00:00 +0000

原题地址

知识点：DP

解题报告

#include <cstdio>
#include <algorithm>
#include <iostream>

using namespace std;

// j部分定义成 31 时不行？ 向前计算的时候有移动 0，..., 30次，共 31 个状态，因此要定义成 32
// d[第i+1分钟][已经移动j次][位于第mov(j)+1棵树] 暴力搜索出结果
int d[1000][32][2];
int T, W;
int apple[1000];

// 因为已知 j 的时候我们已经能够直接算出 k，因此可以直接移除 k 层不必要的循环，使得整个算法更快
int mov(int a) {
  if ((a & 0x1) == 0) return 0;
  return 1;
}

int main() {
  scanf("%d %d", &T, &W);
  int i, j, k;
  for(i=0;i<T;++i) {
    scanf("%d", &apple[i]);
    apple[i]--;
  }
  if (apple[0] == 0) {
    d[0][0][0] = 1;
    d[0][1][1] = 0;
  } else {
    d[0][0][0] = 0;
    d[0][1][1] = 1;
  }

  for(i=0;i<T-1;++i) {
    for(j=0;j<=W;++j) {
      if (mov(j) == apple[i+1]) {
        d[i+1][j][mov(j)] = max(d[i+1][j][mov(j)], d[i][j][mov(j)] + 1);
        d[i+1][j+1][mov(j+1)] = max(d[i+1][j+1][mov(j+1)], d[i][j][mov(j)]);
      } else {
        d[i+1][j+1][mov(j+1)] = max(d[i+1][j+1][mov(j+1)], d[i][j][mov(j)] + 1);
        d[i+1][j][mov(j)] = max(d[i+1][j][mov(j)], d[i][j][mov(j)]);
      }
    }
  }
  cout << *max_element(d[T-1][0], d[T-1][0] + 2*(W+1)) << endl;
  return 0;
}

poj 2229 Sumsets

Thu, 12 Jul 2018 00:00:00 +0000

原题地址

知识点：DP

解题报告

#include <cstdio>
#include <string.h>

int sum;
int d[1000001];

int main() {
  scanf("%d", &sum);
  int i;
  // 初始化唯一确定方案数，d[1] 为 1 表示 1 的分解方案只有 1 种
  d[1] = 1;
  for(i=2;i<=sum;++i) {
    // 找规律，当 i 为偶数的时候方案数为 i / 2 的方案数再加上 i-1的方案数
    // 当 i 为偶数时才体现出 2 的幂之和，因为除了加 1 之外其余加的都是为偶数的2的n次幂，这个是重要的入手点
    if ((i & 0x1) == 0) {
      d[i] = d[i/2];
    }
    // 不论奇偶都要加上他们前一个数的方案数
    d[i] += d[i-1];
    // WA 的时候仔细再看题目才发现要取一下模
    d[i] %= 1000000000;
  }

  printf("%d\n", d[sum]);

  return 0;
}

结语

重点关注题目数字的特征

poj 3176 Cow Bowling

Wed, 11 Jul 2018 00:00:00 +0000

原题地址

知识点：DP

解题报告

#include <cstdio>
#include <algorithm>
#include <iostream>

using namespace std;

int a[350][350];
int d[350][350];
int N;

int main() {
  scanf("%d", &N);
  int i, j;
  for(i=0;i<N;++i) {
    for(j=0;j<i+1;++j) {
      scanf("%d", &a[i][j]);
    }
  }

  d[0][0] = a[0][0];
  for(i=0;i<N-1;++i) {
    for(j=0;j<=i;++j) {
      // 注意这里记忆计算让重叠路径的值最大的技巧
      d[i+1][j+1] = max(d[i+1][j+1], d[i][j] + a[i+1][j+1]);
      d[i+1][j] = max(d[i+1][j], d[i][j] + a[i+1][j]);
    }
  }

  cout << *max_element(d[N-1], d[N-1]+N) << endl;
  return 0;
}

Poj 3262 Protecting the Flowers

Wed, 11 Jul 2018 00:00:00 +0000

原题地址

知识点：贪心

解题报告

#include <cstdio>
#include <iostream>
#include <algorithm>
#include <vector>

using namespace std;

struct P {
  int t, d;
};

// 贪心使得代价最小
// cost = 2 * T * (total - D)
// 因此 D越大，T越小越好
// 重点：转换成 D / T 越大越好
bool cmp(const P &a, const P &b) {
  return b.d * a.t < a.d * b.t;
}

vector<P> v;

int N;

int main() {
  scanf("%d", &N);
  int i, total;
  total = 0;
  for(i=0;i<N;++i) {
    struct P p;
    scanf("%d %d", &p.t, &p.d);
    v.push_back(p);
    total += p.d;
  }

  sort(v.begin(), v.end(), cmp);  
  unsigned long long res = 0;
  for(i=0;i<N;++i) {
    total -= v[i].d;
    res += total * v[i].t * 2;
  }

  cout << res << endl;
  return 0;
}

poj 1017 Packets

Tue, 10 Jul 2018 00:00:00 +0000

知识点：贪心

解题报告

#include <cstdio>
#include <algorithm>

int square[7];

// 解法：每次都先放最大

int solve() {
  int res = 0;
  // 6x6 直接成一块
  res += square[6];
  // 5x5 先成一块，再补 1x1
  res += square[5];
  square[1] -= 11 * square[5];
  // 4x4 先成一块，然后再补 2x2, 1x1
  res += square[4];
  int remain = 20 * square[4];
  while(remain != 0) {
    if (square[2] > 0) {
      square[2]--;
      remain-=4;
    } else if (square[1] > 0) {
      square[1]--;
      remain--;
    } else {
      break;
    }
  }

  // 3x3 优先使用 3x3 自成一块，然后才是 2x2, 1x1
  res += square[3] / 4;
  square[3] %= 4;
  if (square[3] > 0) {
    res++;
    int a;
    // 陷阱：2x2 在补的时候有数量限制！分情况
    switch(square[3]) {
      case 1:
      a = 5;
      remain = 27;
      break;
      case 2:
      a = 3;
      remain = 18;
      break;
      case 3:
      a = 1;
      remain = 9;
      break;
    }
    while(remain && a && square[2] > 0) {
      remain-=4;
      square[2]--;
      a--;
    }
    square[1]-=remain;
  }

  // 如果 2x2 还有剩，自成一块，多出来的再和 1x1 继续拼
  if (square[2] > 0) {
    res += square[2] / 9;
    square[2] %=9;
    if (square[2] > 0) {
      res++;
      square[1] -= 36 - 4 * square[2];
    }
  }
  // 如果 1x1 还有剩，只能自成一块
  if (square[1] > 0) {
    res += square[1] / 36;
    if (square[1] % 36) res++;
  }
  return res;
}

int main() {
  int i;
  while(1) {
    for(i=1;i<=6;i++) {
      scanf("%d", &square[i]);
    }
    if (square[1]+square[2]+square[3]+square[4]+square[5]+square[6] == 0) {
      break;
    }
    printf("%d\n", solve());
  }
  return 0;
}

poj 3040 Allowance

Tue, 10 Jul 2018 00:00:00 +0000

知识点：

贪心

解题报告

#include <cstdio>
#include <iostream>
#include <algorithm>
#include <vector>
#include <string.h>
#include <limits>

using namespace std;

struct Coin {
  int d;
  int b;
};

bool cmp(const Coin &a, const Coin &b) {
  return a.d > b.d;
}

vector<Coin> v;
int N, C;
int need_count[20];

int main() {
  scanf("%d %d", &N, &C);
  int res = 0;
  for(int i=0;i<N;i++) {
    struct Coin c;
    scanf("%d %d", &c.d, &c.b);
    if (c.d >= C) {
      res += c.b;
      continue;
    }
    v.push_back(c);
  }

  sort(v.begin(), v.end(), cmp);
  N = v.size();

  int i, j;
  while(1) {
    int sum = C;
    memset(need_count, 0, sizeof(need_count));
    // 从大到小贪到刚好 sum 或是接近 sum
    for(i=0;i<N;++i) {
      if (sum > 0 && v[i].b > 0) {
        int has = min(v[i].b, sum / v[i].d);
        if (has > 0) {
          sum -= has * v[i].d;
          need_count[i] = has;
        }
      }
    }

    // 从小到大贪到 sum
    for(i=N-1;i>=0;--i) {
      if (sum > 0 && v[i].b > 0) {
        // 允许超过一个面值来凑够 sum
        int has = min(v[i].b - need_count[i], (sum+v[i].d-1) / v[i].d);
        if (has > 0) {
          need_count[i] += has;
          sum -= has * v[i].d;
        }
      }
    }

    if (sum > 0) break;

    int weeks = numeric_limits<int>::max();
    for(i=0;i<N;++i) {
      if (need_count[i] == 0) continue;
      // 对 C 的最优解所能满足的次数，即 weeks
      weeks = min(weeks, v[i].b / need_count[i]);
    }
    res += weeks;
    // 最后更新剩余金币数量
    for(i=0;i<N;++i) {
      if (need_count[i] == 0) continue;
      v[i].b -= weeks * need_count[i];
    }
  }
  
  printf("%d\n", res);
  return 0;
}

结语

经典贪心好题，重点学习贪心的思维方式

poj 1979 Red and Black

Thu, 28 Jun 2018 00:00:00 +0000

知识点：DFS

solution

#include <cstdio>

int W, H;
char tile[25][25];
int pos_x, pos_y;
int sh_x[4] = {0, 0, -1, 1};
int sh_y[4] = {1, -1, 0, 0};
int res = 0;

void solve(int x, int y)
{
  tile[y][x] = '#';
  res++;
  
  for (int i=0;i<4;i++) {
    int new_x = x + sh_x[i];
    int new_y = y + sh_y[i];
    if (new_x >= 0 && new_x <W && new_y >=0 && new_y < H && tile[new_y][new_x] != '#') {
      solve(new_x, new_y);
    }
  }
}

int main()
{

  while (1)
  {
    scanf("%d %d", &W, &H);
    getchar();
    if (!W && !H) {
      break;
    }

    for (int i = 0; i < H; i++) {
      fgets(tile[i], 25, stdin);
      tile[i][W] = '#';
    }

    for (int i=0;i<H;i++) {
      for (int j=0;j<W;j++) {
        if (tile[i][j] == '@') {
          pos_x = j;
          pos_y = i;
        }
        if (i==H-1) {
          tile[H][j] = '#';
        }
      }
    }

    solve(pos_x, pos_y);
    printf("%d\n", res);
    res = 0;
  }
  return 0;
}

通过Go HTTP Client的报错看标准库https请求

Thu, 28 Jun 2018 00:00:00 +0000

在用 Go 自带的 http client 进行默认 Get 操作的时候，发现如下错误

x509: certificate signed by unknown authority

这个报错来自 crypto/x509 中关于证书签名的验证

负责验证证书的方法签名

func (c *Certificate) Verify(opts VerifyOptions) (chains [][]*Certificate, err error)

关于 x509

这是一种自签名证书，x509证书中包含着一个证书链 (Certificate Chain)，包含根证书，中间证书即CA证书，和用户证书。根证书因为需要预装在用户系统中，因此引入中间证书来更好地普及和扩展证书，因此当系统要验证一个证书是否为合法时的思路就是，先验证中间证书，根据中间证书得到颁发这个中间证书的根证书签名(有可能还是中间证书，因此要一直向上寻找到根证书)，然后再通过系统内置的根证书进行验证，如果通过，则由此CA证书颁发的用户证书为可信的有效证书，否则为无效

继续阅读源码

Go 在验证的时候在 crypto/x509 中实现了关于证书链构建与验证

// 当前证书不是根证书时开始 DFS 构建证书链
func (c *Certificate) buildChains(cache map[int][][]*Certificate, currentChain []*Certificate, opts *VerifyOptions) (chains [][]*Certificate, err error) {
    // 查找当前中间证书证书的根，也就是当前证书的根颁发者
    possibleRoots, failedRoot, rootErr := opts.Roots.findVerifiedParents(c)
nextRoot:
    // 遍历每个可能的根证书颁发者
    for _, rootNum := range possibleRoots {
        // 拿到颁发者的证书
        root := opts.Roots.certs[rootNum]

        for _, cert := range currentChain {
            if cert.Equal(root) {
                // 在已有证书链中，不需要验证
                continue nextRoot
            }
        }

        // 不在已有证书链中，需要验证是否为根证书
        err = root.isValid(rootCertificate, currentChain, opts)
        // 即便验证有错误，依然继续后面的验证，因为颁发者只是可能为链的根证书
        if err != nil {
            continue
        }
        // 找到根，将根证书添加到已有链中，并添加到 chains，最后验证 chains 的长度来确定是否成功构建了到跟的证书链
        // appendToFreshChain 将现有链进行复制，容量+1，用来存放 root 证书
        chains = append(chains, appendToFreshChain(currentChain, root))
    }

    // 查找当前证书可能的中间证书颁发者
    possibleIntermediates, failedIntermediate, intermediateErr := opts.Intermediates.findVerifiedParents(c)
nextIntermediate:
    // 查找中间证书与查找根证书类似
    for _, intermediateNum := range possibleIntermediates {
        intermediate := opts.Intermediates.certs[intermediateNum]
        for _, cert := range currentChain {
            if cert.Equal(intermediate) {
                continue nextIntermediate
            }
        }
        err = intermediate.isValid(intermediateCertificate, currentChain, opts)
        if err != nil {
            continue
        }
        var childChains [][]*Certificate
        childChains, ok := cache[intermediateNum]
        if !ok {
            // 深度搜索当前中间证书的上游构建证书链
            childChains, err = intermediate.buildChains(cache, appendToFreshChain(currentChain, intermediate), opts)
            // cache 用于记忆已构建的中间证书链
            cache[intermediateNum] = childChains
        }
        // 添加含有中间证书的链到 chains 构成完整的从根开始的证书链
        chains = append(chains, childChains...)
    }

    // 构建结束，证书链构建成功，有且只有唯一的一条经验证的证书链
    if len(chains) > 0 {
        err = nil
    }

    // 证书链构建失败，错误未知
    if len(chains) == 0 && err == nil {
        hintErr := rootErr
        hintCert := failedRoot
        if hintErr == nil {
            hintErr = intermediateErr
            hintCert = failedIntermediate
        }
        // 上文提到的报错的来源
        err = UnknownAuthorityError{c, hintErr, hintCert}
    }

    // error 已经用命名返回变量err捕捉，直接回传即可
    return
}

好了，现在我们知道这个错误的产生，源于无法构建有效的证书链

那么，这与 http client 有什么联系？我们顺藤摸瓜继续往上看

分别在 crypto/tls 的 handshake_client.go 和 handshake_server.go 中都有出现验证证书的过程

// client
c.verifiedChains, err = certs[0].Verify(opts)
// server
chains, err := certs[0].Verify(opts)

这就不得不再次复习一下 https 连接建立的过程了

https 连接的建立

SSL或TLS握手示意图

通过图我们可以直观地看到在步骤3和步骤6的时候，会发生证书的验证，在 Go 的 http client中，显然是使用 handshake_client.go 中的 Verify 来验证服务器的证书

func (c *Conn) Handshake() error {
    // 当前连接的握手必须互斥，因此这里加了锁
    c.handshakeMutex.Lock()
    defer c.handshakeMutex.Unlock()
    if err := c.handshakeErr; err != nil {
        return err
    }
    if c.handshakeComplete {
        return nil
    }
    c.in.Lock()
    defer c.in.Unlock()
    if c.isClient {
        // 是客户端的握手
        c.handshakeErr = c.clientHandshake()
    } else {
        // 是服务端握手
        c.handshakeErr = c.serverHandshake()
    }
    if c.handshakeErr == nil {
        c.handshakes++
    } else {
        // If an error occurred during the hadshake try to flush the
        // alert that might be left in the buffer.
        c.flush()
    }
    if c.handshakeErr == nil && !c.handshakeComplete {
        panic("handshake should have had a result.")
    }
    return c.handshakeErr
}

从 conn.go 的源码中我们可以发现使用 isClient 属性来区分是客户端握手还是服务端的握手。在开发环境中，可能我们需要临时使用自己的自签名证书来进行 https 通信，如何跳过这个验证证书的过程呢？我们接着 clientHandshake() 往下看

关于 TLS 会话

当然，我们不能每次建立 https 通信的时候都重新握一次手，因此通过为 https 引入状态将 TLS 握手状态在用会话记录下来，能够大大减少服务器的压力, 早期的 TLS 会使用 Session ID 来记录，因为负载均衡的存在，事实上只有第一次握手时被分配到的物理机器上才有客户端 Session ID 的记录，当第二次访问的时候，我们并不能指望负载均衡算法能够再次将请求分配给同一台物理机器，其中一种解决方案是负责握手的服务器将 Session ID 存储到 redis 或者 memcached 集, 当第二次访问的时候统一去查询缓存，但让服务器在一段时间记住状态可能会暴露潜在的扩展性问题。于是，TLS v1.2 引入了会话凭证 (session ticket) ，将会话状态的存储交给客户端，第一次握手结束时，服务器会下发经过会话密钥 (Session key) 加密的会话凭证，之前会话的相关状态都会保存在会话凭证中并由客户端保存，当第二次进行握手的时候，客户端需要将本地缓存的会话凭证包含在客户端握手消息中，只要服务器能够共享同一会话密钥，那么这台服务器就能够解密得到之前的会话状态，因为会话密钥不具备向前安全性，因此需要定期轮换更新密钥

客户端握手过程

func (c *Conn) clientHandshake() error {
    if c.config == nil {
        // 没有传入自定义的client设置，则使用默认设置
        c.config = defaultConfig()
    }
    // 可能是首次握手，因此相关的会话状态需要更新
    c.didResume = false
    // 构造 Client Hello 报文消息
    hello, err := makeClientHello(c.config)
    if err != nil {
        return err
    }
    if c.handshakes > 0 {
        hello.secureRenegotiation = c.clientFinished[:]
    }
    var session *ClientSessionState
    var cacheKey string
    sessionCache := c.config.ClientSessionCache
    // 检查是否支持会话凭证
    if c.config.SessionTicketsDisabled {
        sessionCache = nil
    }
    if sessionCache != nil {
        hello.ticketSupported = true
    }
    // 如果已经保存了会话凭证，且处于最开始的 "Client Hello" 阶段，如果处于发送客户凭证(step 5)的阶段，则跳过会话恢复
    if sessionCache != nil && c.handshakes == 0 {
        // 尝试得到先前 TLS 的会话状态
        cacheKey = clientSessionCacheKey(c.conn.RemoteAddr(), c.config)
        candidateSession, ok := sessionCache.Get(cacheKey)
        if ok {
            // 检查之前会话使用的加密组件是否能继续延用
            cipherSuiteOk := false
            for _, id := range hello.cipherSuites {
                if id == candidateSession.cipherSuite {
                    cipherSuiteOk = true
                    break
                }
            }
            versOk := candidateSession.vers >= c.config.minVersion() &&
                candidateSession.vers <= c.config.maxVersion()
            if versOk && cipherSuiteOk {
                session = candidateSession
            }
        }
    }
    if session != nil
        hello.sessionTicket = session.sessionTicket
        // 生成随机的 session ID，如果服务器拒绝了客户端的会话凭证并触发一次完整的握手，那么我们可以通过这个 ID 探知此服务器是否支持会话恢复
        hello.sessionId = make([]byte, 16)
        if _, err := io.ReadFull(c.config.rand(), hello.sessionId); err != nil {
            return errors.New("tls: short read from Rand: " + err.Error())
        }
    }
    hs := &clientHandshakeState{
        c:       c,
        hello:   hello,
        session: session,
    }
    // 这里正式开始进行握手
    if err = hs.handshake(); err != nil {
        return err
    }
    // 如果成功完成握手，服务器下发了新的会话凭证，那么则更新本地缓存的会话凭证
    if sessionCache != nil && hs.session != nil && session != hs.session {
        sessionCache.Put(cacheKey, hs.session)
    }
    return nil
}

如果是客户端类型的握手，那么客户端会发出 Client Hello 的报文给服务端

func (hs *clientHandshakeState) handshake() error {
    c := hs.c
    // 发送 ClientHello 报文
    if _, err := c.writeRecord(recordTypeHandshake, hs.hello.marshal()); err != nil {
        return err
    }
    msg, err := c.readHandshake()
    if err != nil {
        return err
    }
    var ok bool
    if hs.serverHello, ok = msg.(*serverHelloMsg); !ok {
        c.sendAlert(alertUnexpectedMessage)
        return unexpectedMessageError(hs.serverHello, msg)
    }
    // ...
    // 解析服务端发回的 ServerHello 报文
    isResume, err := hs.processServerHello()
    if err != nil {
        return err
    }

    if isResume {
        // 恢复已有的会话状态，不需要继续进行握手
        if err := hs.establishKeys(); err != nil {
            return err
        }
        if err := hs.readSessionTicket(); err != nil {
            return err
        }
        if err := hs.readFinished(c.serverFinished[:]); err != nil {
            return err
        }
        c.clientFinishedIsFirst = false
        if err := hs.sendFinished(c.clientFinished[:]); err != nil {
            return err
        }
        if _, err := c.flush(); err != nil {
            return err
        }
    } else {
        // 首次握手，继续完成完整的握手，从服务端的报文中解析获取证书凭证
        if err := hs.doFullHandshake(); err != nil {
            return err
        }
        if err := hs.establishKeys(); err != nil {
            return err
        }
        if err := hs.sendFinished(c.clientFinished[:]); err != nil {
            return err
        }
        if _, err := c.flush(); err != nil {
            return err
        }
        c.clientFinishedIsFirst = true
        // 拿到会话凭证，下次请求就不需要完整的走一遍握手了
        if err := hs.readSessionTicket(); err != nil {
            return err
        }
        if err := hs.readFinished(c.serverFinished[:]); err != nil {
            return err
        }
    }
    c.ekm = ekmFromMasterSecret(c.vers, hs.suite, hs.masterSecret, hs.hello.random, hs.serverHello.random)
    c.didResume = isResume
    c.handshakeComplete = true
    return nil
}

现在思路逐渐清晰，如果想要跳过证书验证的步骤，使用自签名的证书，只需要跳过第一次完整握手时验证证书凭证即可

从 hs.doFullHandshake() 继续往下看

func (hs *clientHandshakeState) doFullHandshake() error {
    // 检查报文中包含的证书内容
    // ...
    if c.handshakes == 0 {
        // 初次握手，需要验证服务端证书
        certs := make([]*x509.Certificate, len(certMsg.certificates))
        for i, asn1Data := range certMsg.certificates {
            cert, err := x509.ParseCertificate(asn1Data)
            if err != nil {
                c.sendAlert(alertBadCertificate)
                return errors.New("tls: failed to parse certificate from server: " + err.Error())
            }
            certs[i] = cert
        }
        // 重点：只需通过修改 config 即可跳过这个验证步骤!!
        if !c.config.InsecureSkipVerify {
            opts := x509.VerifyOptions{
                Roots:         c.config.RootCAs,
                CurrentTime:   c.config.time(),
                DNSName:       c.config.ServerName,
                Intermediates: x509.NewCertPool(),
            }
            for i, cert := range certs {
                if i == 0 {
                    continue
                }
                opts.Intermediates.AddCert(cert)
            }
            // 这个是我们想跳过的步骤
            c.verifiedChains, err = certs[0].Verify(opts)
            if err != nil {
                c.sendAlert(alertBadCertificate)
                return err
            }
        }
    }
    // ...
}

最后，我们只需要几行代码配置一下我们的 HTTP Client 即可跳过证书的验证

var (
    once     sync.Once
    instance *http.Client
)

func New() *http.Client {
    once.Do(func() {
        tr := &http.Transport{
            // 简单配置一下
            TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
        }
        instance = &http.Client{
            Timeout:   8 * time.Second,
            Transport: tr,
        }
    })
    return instance
}

如果想要区分生产环境和开发环境，只需要简单用 go build 在编译时区分一下环境即可

通过一个报错追根溯源，借机将 https 的请求过程在标准库源码的基础上又复习了一遍，可谓收获颇丰，如有疏忽，恳请各位大佬指正。

参考资料

LeetCode题解:最长回文串之manacher算法

Tue, 17 Apr 2018 00:00:00 +0000

manacher 俗称马拉车算法，也是本文的主角，是一种能够将最长回文串的求解复杂度降低到 O(N) 的一种高效算法，当我第一次见到求解最长回文串的题目时，首先采用的就是暴力解法，O(N平方) 复杂度遍历所有可能的串，然后再用 O(N) 的时间来求回文串的最大长度，使用 map 存储各个下标对的回文情况尽管能减少一部分计算，但是显然这种方式时间复杂度过高，部分 case 容易超时

这种算法的大概思路如下：

通过插入一些符号简化奇偶个数和边界对判断回文串的干扰
中心点的整个边界(除去中心点)的一半恰好等于中心点的最大回文串长度
利用大回文串边界内的位置的最大回文串个数以大中心点对称的规律大大简化计算量

本人使用 Go 语言实现上述算法详细代码如下：

// LeetCode No.5 Longest Palindromic Substring
func longestPalindrome(s string) string {
    // 方便我们后面直接使用切片操作获得结果
    origin := []byte(s)

    // 一个字母不考虑回文
    if len(origin) == 1 {
        return s
    }

    var maxCenterIndex int

    bs := process(s)
    p := make([]int, len(bs))

    c := 0
    r := 0

    for i:=1;i<len(bs)-1;i++{
        // mirror 是 i 以 c 为对称轴的对称下标
        mirror := 2*c-i

        // 当有右边界的时候
        if r > i {
            // 边界不越过大回文串的串中心的最大回文串长度与对称位置的最大回文串长度相等
            if r-i > p[mirror] {
                p[i] = p[mirror]
            } else {
                // 边界越过时 i 位置的最大回文串长度至少等于 i 到边界的长度
                p[i] = r-i
            }
        }

        // 计算位置 i 的最大回文串长度，之前的计算 p[i] 的步骤节省了大量的回文比较
        // 注意 +1 和 -1 除去自己与自身相比较的情况
        for bs[p[i]+i+1] == bs[i-p[i]-1] {
            p[i]++
        }

        // 边界扩大的时候重新计算中心点
        if i+p[i] > r {
            r = i+p[i]
            c = i
        }

        // 每一轮计算都能得到以 bs[i] 为中心的最大回文串长度，这里我们维护一个最大的即可
        if p[maxCenterIndex] < p[i] {
            maxCenterIndex = i
        }
    }

    mx := p[maxCenterIndex]

    // 由中间串的中心位置计算源串的起始位置
    startIndex := (maxCenterIndex - 1) / 2 - mx/2
    endIndex := startIndex + mx
    return string(origin[startIndex:endIndex])
}

// 使用 buffer 高效处理原串，目的是处理掉原串奇偶个数以及边界带来的问题，使算法的实现更加简洁
// eg: input - "abcabc" -> output - "^#a#b#c#a#b#c#$"
// ps: Go 1.10 版本已支持 stringBuilder
func process(s string) []byte {
    bs := []byte(s)
    var buffer bytes.Buffer
    buffer.WriteString("^")
    for _,b := range bs {
        buffer.WriteString("#")
        buffer.WriteByte(b)
    }
    buffer.WriteString("#$")
    return buffer.Bytes()
}

无缓冲通道引发的BUG

Wed, 11 Apr 2018 00:00:00 +0000

最近在刚玩具级的 MapReduce ，其中充斥着大量的并发编程的代码，稍有不慎就可能导致 Map 或者 Reduce 的时候遭遇到未知的阻塞状态 (Blocking)，导致整个系统无法按照计划处理所有的 Task 并将输出的结果写入文件，经过一番 DEBUG ，发现竟是无缓冲通道的基本用法没有掌握熟练，当遇上多个 channel 协作的时候就难免会踩坑

先说重点：

无缓冲通道要求发送方和接收方同时准备好，才能"进行"发送和接收操作

show me the code

在 Task 的容错阶段我们要 re-execute 那些失败的任务，我的方法是将每个任务的执行结果保存在一个布尔数组里，下标对应每个任务，元素对应的是当前 Task 是否完成

for t, failed := range taskFailed {
    if failed == true {
        wg.Add(1)
        addr := <-registerChan
        go func(i int, workerAddr string, p jobPhase) {
            res := call(workerAddr, "Worker.DoTask", DoTaskArgs{
                JobName:       jobName,
                File:          mapFiles[i],
                Phase:         p,
                TaskNumber:    i,
                NumOtherPhase: n_other,
            }, nil)
            if res == true {
                registerChan <- workerAddr
                wg.Done()
            }
        }(t, addr, phase)
    }
}

wg.Wait()

我们遍历了任务状态数组，找出那些失败的任务，让空闲的 worker 去执行，然后一直 WaitGroup 就行了

但仔细观察，联系刚才说到的无阻塞通道的双方都要准备好才能进行操作，那么言外之意，如果只是一方在进行操作，但是另一方根本没上线的情况下，那么这个操作将会阻塞 goroutine

看回代码的这两行

registerChan <- workerAddr
wg.Done()

注意这个时候未必有对应的 registerChan 接收者，因为我们只为失败的 Task 重新分配 Worker，因此如果只有一个 Task 失败的话，wg.Wait() 将永远阻塞下去，因此我们应该调换一下顺序

wg.Done()
registerChan <- workerAddr

这样才不会让 WaitGroup 一直阻塞下去

分布式初探 Distributed 101

Fri, 06 Apr 2018 00:00:00 +0000

什么是分布式系统？

使用多机来处理单机相同问题的系统

多点存储，多点计算

为什么需要分布式系统？

解决日益增长的存储资源和计算资源占用的问题，分散系统压力

分布式需要解决的三大问题

存储
传输(通信)
计算

分布式系统的目标

能够通过购买 N 多硬件来应对 N 数量级增长的问题

分布式系统的性质

扩展性 Scalability

可分为三个维度：

数量级扩展：节点的数量增加应该让整个系统线性提速，数据量的增加不应该增加延迟
地理扩展：使用异地数据中心降低用户响应时间，合理处理跨数据中心的响应延迟
调度扩展：增加更多的节点不应该增加整个系统管理的负担

性能 Performance

给定任务能够快速处理完成（低延迟）
高吞吐量（任务处理率）
占用较少的计算资源

这些因素需要不断地权衡，其中低延迟可以说是最为重要的因素，常与物理上的限制相关，这种问题难以用金钱解决

延迟：指的是某事件发生直到其产生影响或可见时的那一段过程

一个数据完全不发生改变的系统不应该有延迟问题

理想状态下的最低延迟取决于信息所要经过的物理距离

可用性 (容错性) Availability and Fault Tolerance

分布式系统优于单机的一个点在于单机无法容错，要么成功，要么失败

分布式系统可以容纳一群不可靠的组件，在顶层建立起一个可靠的系统

毫无冗余的系统的可用性与其组件相同，含有冗余设计的系统可以容许部分失败因此具有高可用性

可用性 = 在线时间 / (在线时间 + 死时间)

容错：在错误发生时能够按设定好的方式继续工作的能力

简而言之，我们无法容忍那些我们没有预知的错误

分布式系统的限制

物理上：

节点的个数
节点之间的距离

如果增加节点的个数：会降低系统的可用性，增加管理的开销，节点间通讯的开销会降低性能进而增加等待时间（与物理距离相关）

性能与可用性可以使用系统对外部的保证（可靠性）来界定，这种保证是不同服务之间的协议，例如：在这个点写入的数据，在其他点读取的这个数据能有多快？写完的数据能不能保证被持久化？一个计算请求能在多长时间内返回结果？如果有组件失效，对整个系统会有什么样的影响？

错误是不正确的行为，异常是未知的行为

系统抽象与建模

好的抽象使系统更容易理解

对外隐藏细节的系统更加容易理解，但暴露更多细节的系统能够得到更好的优化

理想的系统既有清晰的表达又满足业务需要

设计精髓：分治和复制 Partition and replicate

对于一份数据集来说，它能够被分成多个小份以便分配到多个节点实现并行处理(分治)，也可以被复制或缓存到不同的节点以减少客户端和服务端之间的距离提高容错性。

分治

将数据分成不同且独立的子集，解决数据量的不断增长，提高了处理性能和可用性，分割的依据和访问数据的主要方式相关，要解决独立子集的一些问题（如不同子集间的低效访问）

复制

使新的计算资源应用到新的拷贝数据中，降低等待时间又增强了可用性

复制可增强扩展性，性能和可靠性

复制可以避免单点失败，加速计算，缓存IO提高吞吐

复制带来的问题：

集群数据同步（保持数据一致性）

一致性模型的选择至关重要：强一致性的模型允许你的程序能够像对待一份数据那样去编程，而弱一致性的模型能带来更低的延迟和更高的可用性

参考资料：

http://book.mixu.net/distsys/

0交换排序 Google笔试题

Thu, 29 Mar 2018 00:00:00 +0000

题目:

长度为n的数组乱序存放着0至n-1，现在只能进行0与其他数的交换，请排序这个数组

package main

import "fmt"

func main() {
    s := []int{3, 5, 4, 0, 1, 2, 6}
    for _, v := range s {
        fmt.Printf("%d ", v)
    }
    fmt.Printf("\nafter:\n")

    var i int
    // 先找到 0 并把它放掉第一个位置
    for s[i] != 0 {
        i++
    }
    s[0], s[i] = s[i], s[0]

    i = 1

    for {
        // 从下标为 1 的数字开始，通过与 0 交换将 s[i] 的数字 x 放到 s[x] 处
        for s[i] != i {
            s[s[i]], s[0] = s[0], s[s[i]]
            s[i], s[s[i]] = s[s[i]], s[i]
            // 每次记得把 0 换回原位
            s[i], s[0] = s[0], s[i]
        }
        if i == len(s)-1 {
            break
        }
        // s[i] 排好之后就排 s[i+1]
        i++
    }

    for _, v := range s {
        fmt.Printf("%d ", v)
    }
}

在线运行代码

在 Gin 中实践TDD测试API

Mon, 26 Mar 2018 00:00:00 +0000

如果这篇文章能够从此让你放下手中的快递员，从此开始做一个 TDD First 的 programmer ，那么本文的目的也就达到了

Why TDD is so important?

TDD 的重要性最直接的体现就是 No guessing 和 Robust，一切都在测试的意料之中，同时也确保你自己考虑清楚了所有的情况。而不是直接将你的代码或API接口丢给测试人员，然后根据反馈再继续修改，这样一来一回实际上十分降低效率，那么当我们意识到这一点时，为什么我们不能自己先将大部分的BUG利用测试事先发现并改掉呢？

其次，当系统的规模不断变大，新的功能不断加入进来，这时系统的单元测试有利于我们进行系统的重构，通过代码覆盖率定位到死代码（Dead Code），通过查看调用次数将一些已经非常健壮的代码独立成包或 module，实现增量编译等，在避免臃肿，加快构建速度等改善系统腐化的问题中，测试绝对是功不可没。

TDD can effect code quality

优先编写可测试的类或函数会极大地影响你的代码风格，TDD First 的程序员首先思考的应该是，这个函数的依赖（parameters）是什么？对象实例，基础类型，还是接口？什么样的函数才是容易测试的？这里就不得不提及 Clean Code 的一句名言

Function should do one thing. They should do it well and do it only

当你愿意主动去写测试的时候，你就越希望这些函数是像这样的，无形之中告诉了你的目标函数的模样。有点抽象，但句句重点。简单来说，一个工程的构建通常都是自底向上的，越是灵活的系统切分的粒度应当是越细的，就像搭积木一样，从与数据库直接打交道的数据层，到持久化的 service层 ，基于 RESTful 的 Controller 控制层，校验及权限控制，路由层，日志管理监控等，越高层级的操作越是依赖于低一层级的操作，因此自顶向下对代码健壮性的要求也是越高的。从测试的角度上来看，自底向上看，越是这些细粒度的函数责任越重大，这个层级的测试也是最容易写的，因为它们正是我们说的那种只做一件事的函数。

TDD decrease BUG

试想一下这两种控制器函数

func (ctrl *UserController) Register(user *entity.User) {
    // validate user
    // code ....
    // code ....
    // insert into DB
    // code ....
    // code ....
    // err handle
    // code ....
    // code ....
    // response
}

func (ctrl *UserController) Register(user *entity.User) {
    // ... validate.NewUser(user)
    // err handle ...
    // ... services.AddNewUser(user)
    // err handle ...
    // response ...
}

前一种函数并没有做到 Do one thing，整个函数体十分臃肿，出现 BUG 的可能也越多；第二种控制器函数非常简短，而且基本上在干着一件事，处理错误并将错误响应，倘若校验层和服务层的函数都是经过测试的，那么在控制器出现问题的可能性又降低了一个数量级

TDD is actually faster

Talk is cheap, show me the code

举一个大多数后端开发人员都要写的 end-to-end 测试，以 gin 框架构建的 API 为例， POST json 然后验证返回的 json

准备工作：

func toReader(t interface{}) *bytes.Reader {
    b, _ := json.Marshal(t)
    return bytes.NewReader(b)
}

func toStruct(r *httptest.ResponseRecorder, t interface{}) error {
    resp := r.Result()
    body, _ := ioutil.ReadAll(resp.Body)
    return json.Unmarshal(body, t)
}

func makeJSONReq(method, path string, data interface{}) *http.Request {
    req, _ := http.NewRequest(method, path, toReader(data))
    req.Header.Add("Content-Type", "application/json")
    req.Header.Add("Accept", "application/json")
    return req
}

这些小的通用函数可以封装成测试套件或工具包

对其中一个API接口进行测试：

package api_test

import (
    "bytes"
    "encoding/json"
    "log"
    "net/http"
    "net/http/httptest"
    "os"
    "testing"

    "github.com/stretchr/testify/assert"
    "github.com/yujiahaol68/rossy/app/model/checkpoint"

    "github.com/gin-gonic/gin"

    "github.com/yujiahaol68/rossy/app/database"
    "github.com/yujiahaol68/rossy/app/routers/api"
)

var router = gin.Default()

func setup() error {
    api.Router(router)
    return database.OpenForTest()
}

func TestMain(m *testing.M) {
    err := setup()
    if err != nil {
        log.Fatal(err)
        os.Exit(1)
    }
    defer database.Teardown()

    code := m.Run()
    os.Exit(code)
}

func Test_Source(t *testing.T) {
    t.Log("POST: /api/source")
    check := checkpoint.PostSource{"http://www.infoq.com/cn/feed", 2}

    w := httptest.NewRecorder()
    req := makeJSONReq("POST", "/api/source/", &check)
    router.ServeHTTP(w, req)

    var end endpoint.PostSource
    err := toStruct(w, &end)
    if err != nil {
        t.Fatal(err)
    }

    assert.Equal(t, http.StatusCreated, end.Code)
}

实际要写的测试用例非常短小，如果用 vscode 的话不用离开编辑器就能运行测试。同时对于较大的系统，也不用等所有路由都装载过后再来测试，大大减少启动的等待时间

将视图层分成 checkpoint 和 endpoint 两层分别表示输入的 json 和返回的 json 对应的 struct 描述，对于复杂的 input 还能考虑 mock struct，好处多多，请立即开始你的 TDD 之旅吧！

更多的测试实践可以参考我的示例项目

如有错误，不胜指教。

Go下解析XML文档时的编码问题

Sat, 10 Mar 2018 00:00:00 +0000

最近在弄一些 RSS 解析的东西，记录一下如何解析非UTF-8编码 XML 文档，直接上代码

package rss_test

import (
    "bytes"
    "encoding/xml"
    "fmt"
    "io"
    "testing"

    "github.com/yujiahaol68/rossy/rss"
    "golang.org/x/net/html/charset"
)

func Test_notUTF8(t *testing.T) {
    r := rss.New()

    // 注意不要使用 xml.Unmarshal() 这个方法，仅用于只有 utf-8 编码的情况
    d := xml.NewDecoder(bytes.NewReader([]byte(notUTF8rss)))
    // 设置编码处理函数，utf-8 编码下也可用
    d.CharsetReader = func(s string, reader io.Reader) (io.Reader, error) {
        return charset.NewReader(reader, s)
    }
    err := d.Decode(r)

    if err != nil {
        t.Fatal(err)
    }

    for _, item := range r.ItemList {
        fmt.Printf("* %s\n%s\n", item.Title, item.Link)
    }
}

使用tensorflow的Object Detection API做物体识别

Tue, 06 Feb 2018 00:00:00 +0000

学校有一个实验要做柑橘识别，因此想要用 tensorflow 用自己的训练集训练出一个只识别柑橘的模型出来，故有下文，别的物体识别也可以使用这种方式自己找数据去训练

完整代码

环境准备

Win10
一张优秀的显卡（尤其显存要大，最低要求 2G）
Anaconda
tensorflow 1.5
python 3.5
CUDA 9.0.167 （目前官网的文档可能还是8.0，但亲测 import 寻找的是 9.0 的 dll 文件）
cuDNN 7.0.5
protoc 3.5.1

环境的配置刚开始是比较顺利的，安装了 Anaconda 的话，按照官网的说明可以专门创建一个名为 tensorflow 的 py 环境出来专门用于训练，这也是笔者所推崇的，安装完 tensorflow GPU 的版本，接着就把 CUDA 和 cuDNN 也装了，CUDA 安装目录下的 bin 和 libnvvp 目录都要添加进系统环境变量中， cuDNN 中的 cuda 目录建议解压放置到系统盘根目录并把其下的 bin 目录也添加进环境变量中

为了使用 Object Detection 包，我们必须把 proto 文件手动编译成 python 脚本，将 tensorflow/models 整个下载下来，编译用到的工具为 protoc，下载对应系统的压缩包，解压到系统盘，把其下的 bin 目录添加进环境变量，编译的步骤跟随安装文档， win 下记得把 models 目录和 models/slim 目录都添加进环境变量中，编译成功后运行测试脚本确保 Object Detection 可用，至此 Object Detection 相关的包就处于可用的状态了

注意：如果还是提示找不到对应模块的话，需要在对应环境的 site-packages 目录下加入一个 tensorflow_model.pth 文件，内容如下

第一行是 research 的路径
第二行是 slim 的路径

制作训练集

爬取柑橘的相关图片（其他物体类似）

此步略，自己爬可以，在百度图片搜索结果页右键另存为网页也可以，获取数据不是本文讨论的重点

手动裁剪图片

一方面减小体积，另一方面尽量显示出特征主体，注意主体也不能过大，最好留有一部分背景，没有进行严格的验证

给图片打 Label

win 环境下可以使用 labelimg 给图片的局部加上分类标签来制作我们的数据集，如果是用 mac 的话可以尝试一款名为 rectlabel 的付费 app ，能对图片的分类特征进行更精细的框选，效果应该更好，支持输出 PASCAL VOC 格式的图片标记

生成 TFRecord 文件

我们的图片和 labelimg 生成的分类注解 xml 文件应该按如下方式放置

Project
.
├── annotations
│   ├── xmls
│   │   ├── tangerine_1.xml
│   │   └── tangerine_2.xml
│   └── trainval.txt
│
├── images
│   └── tangerine_1.jpg
│   └── tangerine_2.jpg
├── data
│   └── tangerine_label_map.pbtxt

因为本文使用 labelimg 进行的图片特征标记已经符合 Oxford pet dataset 的格式，所以笔者直接使用的是 models 目录中自带的转换脚本来将我们自己制作的数据集转换成文档所要求的 TFRecord 文件，将输出的文件名称分别改为 tangerine_train.record 和 tangerine_val.record，运行转换脚本，参数 data_dir 也就是上图目录树中 Project 的目录，output_dir 是输出目录， label_map_path 也就是我们 tangerine_label_map.pbtxt 的文件路径，脚本默认是使用 30% 的图片数据作为测试集，可根据自身情况进行修改

留意目录树的童鞋可能会发现，annotations 目录下还有一个 trainval.txt 文件，因为 object detection 需要读取其中的每一行来去读取相应的 xml 文件，然后根据 xml 中的 filename 和 path 标签内容再去读取相应的 jpg 图片。因此，我们需要把所有的 xml 文件名称（不含扩展名）以一个文件一行的形式，写入 trainval.txt 并保证它放在目录树所示位置，每个 xml 文件中的 filename 标签内容也必须修改为带扩展名的形式，这里我自行编写了一些脚本专门用于批量进行自动修改

使用说明：

clean_data.py 用于将同一个目录下的图片和xml文件重命名成规整的名字
gen_trainval.py 用于生成 trainval.txt 文件
xml_modify.py 用于修改 xml 文件的部分内容使得 create_tangerine_tf_record.py 能够顺利通过里面提供的标识找到图片并生成 TFRecord

使用详情请阅读代码注释

选择模型及修改对应配置文件

本文使用的模型为 coco数据集的 faster_rcnn_resnet101 模型，想要使用预训练的模型我们需要将模型的压缩包下载下来，将里面前缀为 model.ckpt 的文件解压到我们的 Project/training 目录下， faster_rcnn_resnet101_coco.config 是对应的模型文件，在里面把对应的 PATH_TO_BE_CONFIGURED 的部分自行进行修改，训练的时候 tensorflow 会通过读取配置文件的形式去读取对应的模型文件，训练集测试集和 label ，如果需要修改训练步数减少训练时间可以修改 num_steps

模型训练及效果查看

训练命令

# 在 research 目录下
$ python object_detection/train.py --logtostderr --pipeline_config_path=E:/DL/tangerine-recognition/faster_rcnn_resnet101_coco.config --train_dir=E:/DL/tangerine-recognition/training

开启 tensorboard 看训练时损失函数的变化情况

$ tensorboard --logdir=E:/DL/tangerine-recognition/training --port=6006 --host=localhost
# 访问 localhost:6006

开启 tensorboard 看模型在测试集上的效果

# 在 research 目录下
$ python object_detection/eval.py --logtostderr --pipeline_config_path=E:/DL/tangerine-recognition/faster_rcnn_resnet101_coco.config --eval_dir=E:/DL/tangerine-recognition/eval --checkpoint_dir=E:/DL/tangerine-recognition/training

$ tensorboard --logdir=E:/DL/tangerine-recognition/eval --port=6006 --host=localhost

# 访问 localhost:6006，右上角选择 image

导出训练好的模型

# 在 research 目录下
$ python object_detection/export_inference_graph.py --input_type image_tensor --pipeline_config_path E:/DL/tangerine-recognition/faster_rcnn_resnet101_coco.config --trained_checkpoint_prefix E:/DL/tangerine-recognition/training/model.ckpt-{设置的步数} --output_directory E:/DL/tangerine-recognition/training/result

在 result 目录下就能看到我们的 frozen_inference_graph.pb 可用于生产部署的图模型了

使用 python 调用已训练的模型进行识别

# demo.py
import cv2
import numpy as np
import tensorflow as tf
from object_detection.utils import label_map_util
from object_detection.utils import visualization_utils as vis_util


class TOD(object):
    def __init__(self):
        self.PATH_TO_CKPT = 'E:\\DL\\tangerine-recognition\\training\\result\\frozen_inference_graph.pb'
        self.PATH_TO_LABELS = 'E:\\DL\\tangerine-recognition\\tangerine_label_map.pbtxt'
        self.NUM_CLASSES = 1
        self.detection_graph = self._load_model()
        self.category_index = self._load_label_map()

    def _load_model(self):
        detection_graph = tf.Graph()
        with detection_graph.as_default():
            od_graph_def = tf.GraphDef()
            with tf.gfile.GFile(self.PATH_TO_CKPT, 'rb') as fid:
                serialized_graph = fid.read()
                od_graph_def.ParseFromString(serialized_graph)
                tf.import_graph_def(od_graph_def, name='')
        return detection_graph

    def _load_label_map(self):
        label_map = label_map_util.load_labelmap(self.PATH_TO_LABELS)
        categories = label_map_util.convert_label_map_to_categories(label_map,max_num_classes=self.NUM_CLASSES,use_display_name=True)
        category_index = label_map_util.create_category_index(categories)
        return category_index

    def detect(self, image):
        with self.detection_graph.as_default():
            with tf.Session(graph=self.detection_graph) as sess:
                # Expand dimensions since the model expects images to have shape: [1, None, None, 3]
                image_np_expanded = np.expand_dims(image, axis=0)
                image_tensor = self.detection_graph.get_tensor_by_name('image_tensor:0')
                boxes = self.detection_graph.get_tensor_by_name('detection_boxes:0')
                scores = self.detection_graph.get_tensor_by_name('detection_scores:0')
                classes = self.detection_graph.get_tensor_by_name('detection_classes:0')
                num_detections = self.detection_graph.get_tensor_by_name('num_detections:0')
                # Actual detection.
                (boxes, scores, classes, num_detections) = sess.run(
                    [boxes, scores, classes, num_detections],
                    feed_dict={image_tensor: image_np_expanded})
                # Visualization of the results of a detection.
                vis_util.visualize_boxes_and_labels_on_image_array(
                    image,
                    np.squeeze(boxes),
                    np.squeeze(classes).astype(np.int32),
                    np.squeeze(scores),
                    self.category_index,
                    use_normalized_coordinates=True,
                    line_thickness=8)

        cv2.namedWindow("detection", cv2.WINDOW_NORMAL)
        cv2.imshow("detection", image)
        cv2.waitKey(0)

if __name__ == '__main__':
    image = cv2.imread('image.jpg')
    detecotr = TOD()
    detecotr.detect(image)

最终效果

参考资料

SQL基础简明总结

Sat, 04 Nov 2017 00:00:00 +0000

Inner Join

只含有关联的行

SELECT field1, RTRIM(field2) AS f2
FROM table_one INNER JOIN table_two
ON table_one.table_two_id = table_two.id
GROUP BY field1, f2
AVING COUNT(table_two.credit) > 2
WHERE condition1 AND condition2 AND field1 LIKE '%@hotmail.com'
ORDER BY field3;

Self Join

可用于替代子查询

SELECT c1.cust_id, c1.cust_name, c1.cust_contact
FROM customers AS c1, customers AS c2
WHERE c1.cust_name = c2.cust_name
AND c2.cust_contact = 'Jim';

Outer Join

包含没有关联行的行

LEFT 指的是 OUTER JOIN 左边的表选择所有行

SELECT customers.cust_id, orders.order_num
FROM customers LEFT OUTER JOIN orders
ON customers.cust_id = orders.cust_id;

UNION

连接多个查询，但必须每个查询的列必须相同

INSERT INTO

INSERT INTO table1(
    field1,
    field2
)
VALUES('a', 2);

VALUES 可替换为 SELECT 来插入检索的数据

SELECT INTO 可用于从表中导出数据到另一个表中

表操作

CREATE TABLE ...
DROP TABLE ...

ALTER TABLE table1
ADD field CHAR(20)
DROP COLUMN deletedField

视图

用于重用SQL语句，一般用于简化复杂的查询语句，或者是过滤数据

CREATE VIEW cv AS
SELECT ...
WHERE ...

SELECT field1, field2
FROM cv
WHERE ...

- 两个where子句会自动组合

事务

批量的SQL语句要么全部执行，要么都不执行或回退到特定语句

用于保证数据的完整性

事务可用于管理增删改语句

START TRANSACTION
...
SAVEPOINT delete1
...
ROLLBACK TO delete1
COMMIT;

- 可以在想结束的地方COMMIT，判断是否出错来执行回退

重要概念

主键每行的唯一标示，值不能够重用，不允许为NULL，不允许用户修改，自动生成，关键词 PRIMARY KEY

外键确保与此列关联的另一表的列存在引用的值，否则会报错，关键词

- 定义中
REFERENCE table1 (field1)
- 更改中
ALTER TABLE table1
ADD CONSTRAINT
FOREIGN KEY (user_id) REFERENCES user (id)

唯一约束 保证列中的值唯一，可包含NULL值，可修改可更新，使用关键词 UNIQUE

检查约束 限定值的范围

ADD CONSTRAINT CHECK ( field > 0 )

索引提前恰当的排序，当查找这个排好序的列时会非常快，主键数据本身就是排序的，提高查找性能，却降低了增删改的性能，因为索引会在这些操作中动态更新索引

关键词 CREATE INDEX

触发器 关联特定表上的增删改操作，约束的性能更佳，使用前可以先考虑使用约束，能用于保持数据库的完整性

Linux必知之网络基础篇

Tue, 31 Oct 2017 00:00:00 +0000

基本层次结构

网络层

当每个主机连接到一个子网的时候，其在子网中就会有一个IP地址，这个IP地址应该是唯一的但是在专用网络和NAT的情况中，会有多个IP地址

查看地址：ipconfig

inet addr: IP地址

Mask: 子网掩码，定义了IP地址的所属

将它们分别写成四个八位二进制数，每位进行对应，将IP中与掩码的1对应的位加粗，剩余未加粗的是可以变动的，从而可以发现子网之中IP的共用IP前缀

如：

255.255.255.0
11111111 11111111 11111111 00000000
子网内的IP的前三位都是相同的，很容易推出子网中其他的IP

路由表

$ route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.135.0.1      0.0.0.0         UG    0      0        0 eth0
10.135.0.0      0.0.0.0         255.255.192.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0

0.0.0.0 是默认路由，能匹配互联网中的所有IP

Destination 表示前缀

Gateway 默认网关列，如果目标地址没有匹配其他网络，那就是将信息从默认网关中发出

Flags的U表示该路由是可活动的可以直接访问，有G的表示需要通过Gateway才可以访问

数据包追踪

常用: ping traceroute

ping用于检测是否有丢包和是否能快速响应

traceroute能显示数据包到目标主机所经过的路由

host 和 DNS

使用 host+域名的命令可以使用系统自带的DNS库找到域名的IP

过程如下：

查询函数位于系统共享库
根据规则查找，一般是先检查 /etc/hosts 文件中的重写（解释了localhost）
若没有，守护进程（常见是dnsmasq和nscd）会对DNS查询请求进行拦截，如果命中缓存，则返回
如还没有，则会找到配置好的DNS服务器IP，发送查询请求
DNS服务器收到后返回域名对应的IP给应用

物理层

基本概念

MAC硬件地址（介质访问控制）
以太网以帧的形式发送信息，帧里除了实际数据还有发送者和接受者的MAC地址
以太网会有不同的类型，那么在网络层的路由器会将其先解包，然后再重新封装发给目标
内核的网络接口沟通了物理层和网络层，这个接口将IP地址和硬件标识对应起来

查看或配置网络接口

$ ifconfig

输出的左面是接口名称，右边是配置以及统计信息

eth0: 计算机第一块以太网网卡

lo: 虚拟的网络接口，全名loopback，指向自己，数据发送到lo时内核只会将其重新包装，并通过lo回复

网络配置管理器

守护进程 NetworkManager 维护网络和连接的信息和配置，在图形界面中的桌面网络连接设置其实就是与这个进程来交互的

DHCP 动态主机配置协议

用过校园网的朋友们应该都十分清楚，每次都需要登录客户端进行验证，然后就能够动态地获取到IP，DNS，子网掩码等相关的网络配置，通常路由器承担了DHCP服务器的角色，其管理和分配其下的连接主机的网络配置，这样就避免了IP冲突或网络变更所带来的影响，主机只向DHCP服务器临时租用IP，到期之后DHCP服务器可以要求更新配置

传输层

传输层的协议使得网络层的包与应用层的需求无缝连接，其中包含有TCP和UDP协议

查看机器上的连接

$ netstat -nt

建立本地和远端机器的TCP连接，本机进程会使用一个端口向远端的公共端口（通常是80）发送一些特殊的数据包，这个过程是我们所熟知的TCP握手连接，这里不进行详细展开，在远端的机器也会启动一个进程来监听这个公共端口，监听方就被成为服务器

而UDP则简单得多，它默认本机与服务器是通路，不会进行校验，直接发送

查看公认端口的数字: /etc/services

好处：使得进程处理发送和接收更加容易，就像处理文件的输出流和输入流那样，同时这一层也做到了包与数据流之间的转换和包的数据校验纠正工作

IP伪装

使用NAT将IP分享给整个私有网络，使得路由器可以作为中介去访问远程主机而远程却只知道它与路由器建立了连接

大致过程如下：

私有网络里的主机要与外界通信，请求会经过路由器
路由器拦截请求，然后自身启动请求去连接目标
连接成功后伪造连接已建立的信息返回给网络里的主机然后作为本机和远程的中介

防火墙

可以在下面的几个场景下设置检查点：

接收数据包时
发送数据包时
将数据包转发到其他主机或网关时

防火墙的策略配置：详情见 iptables

应用层

服务器并不区分发给操作系统的报头和内容，区分只发生于用户空间的服务器程序

多数的网络服务器都是多进程的，至少有一个进程会监听网络端口，接收到一个新的连接时就**fork()一个新的子进程来处理连接，个别的高性能服务器会提前fork()**出辅助进程的来高效处理连接，连接终止，子进程也就终止

这里列举一些常用的诊断命令：

netstat
lsof
tcpdump

RPC（远程程序调用）：通过本地程序调用远程程序（使用程序标识符来区分），让远程返回结果或信息，有些监控系统会用到

参考资料

《精通Linux》第二版

Linux日常之进程内存篇

Tue, 31 Oct 2017 00:00:00 +0000

基本概念

内核：运行于硬件之上，是操作系统的核心，运行于内存中

进程：计算机中运行的所有程序，并由内核统一管理，这些进程组成了用户空间

用户进程：如图形界面的进程，服务器进程，命令行进程这类用户层级的进程

内核在内核模式中运行，能直接访问处理器和内存，不能容错；而用户进程运行于用户模式中，一个进程崩溃不会影响整个系统的运行

线程：比进程更加细粒度的概念，一般所提到的进程都是单线程，多线程的进程的启动会比多进程要更快，主线程会类似fork出来其他的子线程，而且可以方便地相互通信以及共享IO和系统资源

内核对进程和内存的管理

进程：内核决定哪一个进程可以使用CPU
内存：内核管理所有内存，为进程分配内存，包括进程间的共享内存以及空闲内存

理解内核对进程的管理

对单核CPU来说，每一个进程都是轮流使用CPU，CPU会对每一个到来的进程计时，到时即暂停，接着切换至内核模式，内核会记录下CPU和内存的状态，用于恢复被停止的进程，内核执行上一时间段的任务如磁盘读写，然后选择已就绪的进程来执行，内核为新进程准备CPU和内存（也可以是为了之前暂停的进程），内核将时间段告诉CPU，内核将CPU切换回用户模式，然后进程继续使用CPU进行计算

CPU的使用权在进程之间切换的过程叫做上下文切换，内核运行于上下文切换的间隙时间中

系统调用

fork(): 内核创建进程副本

exec()：内核使用exec(program)中的program来替换当前的进程

需要内核帮忙的进程都使用先fork然后exec(..)的方式来请求内核

进程的追踪

常用命令：

进程信息：top和 ps

进程与文件的信息： lsof

追踪系统调用： strace

追踪共享库调用： ltrace

追踪线程

$ ps m

或者 top 下按 H

测量CPU时间

$ top -p pid1

命令文件执行CPU计时

$ /usr/bin/time command

平均负载

$ uptime

表明CPU的繁忙程度，通常web服务器的平均负载较高，进程的启动快，结束也快

平均负载高但是响应慢的话通常是内存性能受到较大的影响，内存不足时会有很多的进程在准备状态，但是没有足够的内存供要执行的进程使用

内存的状态可以使用： free 命令查看

理解CPU，内核与内存的关系

CPU通过MMU（内存管理单元）将进程访问的虚拟地址转换为实际的内存地址，内核辅助MMU将进程使用的内存划分为更小的区域，成为页面，多个页面使用页面表（内核维护的一个数据结构）进行管理，MMU可以通过这个页面表将虚拟地址映射到实际的内存地址，页面的分配是按需分配，按需的过程大致是开始时指令会被加载到页面，如果这个进程的下一个指令被执行的时候之前已加载的内存页面不存在，那么内核就会加载指令需要的内存页面，再让程序恢复执行，如果进程需要更多的内存，也同样需要内核先去获得更多的内存然后再进行分配

内存页面中的错误

轻微内存页面错误：如果需要的内存页面在主内存中但是MMU无法找到，通常是进程想要更多的内存但是MMU中的空间有限时发生
严重内存页面错误：如果需要的页面在主内存中不存在的话，那么内核就会尝试从磁盘等存储媒介中加载，多数的错误会影响系统性能，在第一次从磁盘中加载代码或者是内存不足时极可能出现

查看方式：

$ /usr/bin/time

对CPU和内存进行监控

$ vmstat n // 每n秒刷新一次数据

IO监控

全局

$ iostat

对进程

$ iotop

Linux日常之cron篇

Mon, 30 Oct 2017 00:00:00 +0000

cron 能够让我们创建 linux 的定时任务，是系统的内置服务，通过加入自己的配置来达到在某时间段重复执行任务的目的

crontab

通过执行这个命令，我们可以将我们的 crontab 文件装载到 /var/spool/cron/crontabs 中

文件内格式:

13 04 * * * Command

最开始的五列从左到右依次为分，时，天，月，星期，星号表示每个

分隔符：

, 表示分隔时间点，如： 00 10,12 * * * 的意思是每天的10点和12点

- 表示时间段，又如： 00 10-12 * * * 的意思是每天10点到12点的每个整点时刻

\n 表示每隔n单位的时间，如： */5 * * * * 的意思是每隔5分钟

值得注意的是要运行的执行文件需要使用全局路径

例如： 13 04 * * * /etc/init.d/smb restart

常用参数

$ crontab -l // 列出任务
$ crontab -r name // 删除任务文件
$ crontab -e // 更改并安装任务文件，进入编辑区，编辑完成保存退出即成功

如果是某一时刻一次性的任务调度可以使用 at 命令

一文讲透koa-源码剖析

Tue, 17 Oct 2017 00:00:00 +0000

前言

本文从头开始由浅入深剖析现在十分流行的koa框架的核心源码，适合已经熟练掌握koa框架使用的开发人员阅读

核心机制

现在，让我们从头开始看看koa的内部究竟做了些什么？

// usage
const app = new Koa()

// source code
constructor() {
	super();

	this.proxy = false;
	this.middleware = [];
	this.subdomainOffset = 2;
	this.env = process.env.NODE_ENV || 'development';
	this.context = Object.create(context);
	this.request = Object.create(request);
	this.response = Object.create(response);
}

这就是一切的起源，Koa 类的实例从此诞生，继承自 Events，可得知其子类拥有处理异步事件的能力，然而Koa如何处理，现在还不得而知，先打个问号。但创建实例的过程中，可得知有三个对象作为实例的属性被初始化，分别为 context request response，还有我们非常熟悉的存放所有全局中间件的数组middleware

koa class 图示

// usage 
app.use(async (ctx, next) => {
	// 中间件函数
});

当调用use方法时，在确认它是async函数的情况下，通过push操作，这个函数会被追加到middleware数组中

use(fn) {
    // 类型检查...
    this.middleware.push(fn);
    return this;
}

此时我们已经有了处理的操作，但是koa还并没有真正的跑起来

app.listen(3000);

可以说当开启http服务器的时候，koa才真正能够开始处理我们的http请求，那么这样一个简洁的调用背后具体究竟做了什么呢？

const server = http.createServer(this.callback());
return server.listen(...args);

koa 使用了 node 的原生 http包来创建http服务,所有的秘密都藏匿在 callback() 这个方法中

// source code
const fn = compose(this.middleware);
...
return fn(ctx).then(handleResponse).catch(onerror);

koa 自身还依赖于 koa-compose 模块，从 koa对于 fn 的使用情况来看，middleware 应该是被封装成了一个叫做 fn 的对象，通过传入 context 对象来返回一个 Promise

现在，深入 koa-compose 模块来看看它又对我们的中间件数组做了什么。

// source code
return function (context, next) {
  // last called middleware #
  let index = -1
  return dispatch(0)
  function dispatch (i) {
    if (i <= index) return Promise.reject(new Error('next() called multiple times'))
    index = i
    let fn = middleware[i]
    if (i === middleware.length) fn = next
    if (!fn) return Promise.resolve()	// 递归结束
    try {
      return Promise.resolve(fn(context, function next () {
        return dispatch(i + 1)	// 递归调用dispatch
      }))
    } catch (err) {
      return Promise.reject(err)
    }
  }
}

里面的闭包看起来很眼熟是吗？再对比一下

// usage
app.use(async (ctx, next) => {
    // 中间件函数
});

这里的 Promise.resolve(fn(..)) 帮助我们异步执行的中间件函数，这里的next函数就解释了为什么Koa的中间件调用是递归执行的，它递归调用了 dispatch 函数来遍历数组中的，同时，所有的中间件函数享有同一个 ctx，再回顾一次外部

const handleRequest = (req, res) => {
  res.statusCode = 404;
  const ctx = this.createContext(req, res);
  const onerror = err => ctx.onerror(err);
  const handleResponse = () => respond(ctx);
  onFinished(res, onerror);
  return fn(ctx).then(handleResponse).catch(onerror);
};

return handleRequest;

context 使用node原生的 http 的监听回调函数中的 req res 来进行进一步的封装，意味着对于每一个 http 请求，koa都会创建一个 context 并共享给所有的全局中间件使用，当所有的中间件执行完过后，会将最后要返回的所有数据统一再交还给 res 进行返回，所以我们在每一个中间件中才能够从 ctx 中取得自己所需要的 req 中的数据进行处理，最后 ctx 再把要返回的 body 给原生的 res 进行返回

每一个请求都有唯一一个 context 对象，所有的关于请求和返回的东西都统一放在里面

createContext 方法将 req res 进一步封装

// source code
const context = Object.create(this.context); // 创建一个对象，使之拥有context的原型方法，后面以此类推
const request = context.request = Object.create(this.request);
const response = context.response = Object.create(this.response);

context.app = request.app = response.app = this;
context.req = request.req = response.req = req;
context.res = request.res = response.res = res;
request.ctx = response.ctx = context;
request.response = response;
response.request = request;

本着一个请求一个context的原则，context 必须是作为一个临时对象而存在，所有的东西都必须封进一个对象中，因此 app req res 三个属性就此诞生，但不知道大家是否有一个疑问，为什么 app req res 也同时被封在了 request 和 response 里？

使他们同时共享同一个 app req res 和 ctx，是为了将处理职责进行转移，客户从外部访问，他们只需要一个 ctx 即可获得所有 koa 提供的数据和方法，而 koa 会继续将这些职责进行进一步的划分，比如 request 是用来进一步封装 req 的，response 是用来进一步封装 res的，这样职责得到了分散，降低了耦合，同时共享所有资源使得整个 context 具有了高内聚的性质，内部元素互相都能够访问得到

// source code
context.state = {};

看得出来，其中的 state 就是专门负责保存单个请求状态的空对象，用户可以根据自己的需要来管理里面的内容

// source code
const ctx = this.createContext(req, res);
const onerror = err => ctx.onerror(err);

这个巨大的 ctx 被创建出来的时候在一开始就立马挂载了错误监听器，但在 createContext 中并没有发现这个onerror方法，应该属于其中一个模块的原型方法，经过一番搜索，发现它位于 context.js 这个文件下，这个文件定义了所有的默认 context 对象具有的原型方法

// application.js
// handleRequest()
const onerror = err => ctx.onerror(err);
onFinished(res, onerror);
return fn(ctx).then(handleResponse).catch(onerror);

异步函数运行过程中如果有异常抛出且内部没有自行捕获异常的话， koa 会统一使用 Promise 的catch 语句来进行错误处理，用一个图来表示的话那就是这样

koa 请求处理流程图

到这里我们应该也不难解开本文开头时我们心中的一个疑问，那就是为什么要继承 Events，其实就是为了使用 node 自带的事件监听器来监听一些事件，例如目前所知的 error ，来解耦错误处理这一块的功能

全局的错误处理函数

// source code
// application.js

onerror(err) {
  assert(err instanceof Error, `non-error thrown: ${err}`);

  if (404 == err.status || err.expose) return;
  if (this.silent) return;

  const msg = err.stack || err.toString();
  console.error();
  console.error(msg.replace(/^/gm, '  '));
  console.error();
}

Koa 的内部核心处理流程已经梳理完毕，现在我们再进入内部模块一探究竟

request 模块

大量的 getter setter 充分提取出 node http 所提供的有用的请求相关的属性，还有一些必要的 helper 函数这里不再赘述，API文档中几乎所有的 ctx.req 下的属性都在其下提供，值得一提的是其中的 this ，头疼的 this , 这一块的代码用了大量的 this.req 的方式来访问node原生提供的 http 请求信息(因为我们把 node 的req赋给了context)，当在 koa 外部进行使用时我们是通过 ctx.req.propertyName 的形式 … 没错，我想你也发现了，我们需要绑定我们的 this 使之指向的是 ctx.req，所以在 context.js 模块中使用了代理来将 this 进行正确的绑定，前文提到的使这些模块能够相互访问的赋值代码其实也一定程度减少了this的麻烦事

// 详见 delegates 包
// https://github.com/tj/node-delegates

// Koa context.js
delegate(proto, 'request')
  .method('acceptsLanguages')
  .method('acceptsEncodings')
  .access('query')
  .access('path')
  .access('url')
  .getter('origin')

// delegates 的内部核心实现，通过apply来重新绑定this
proto[name] = function(){
  return this[target][name].apply(this[target], arguments);
};

response 模块

response.js 的内部也同 request.js 中类似，值得一提的是 writable 这个getter，如果请求已经得到相应，那么返回 true，其中读取的值是 this.res.finished，许多的报错中我们常常会碰到关于尝试重复写入响应头 header 的错误，这个错误的来源即使是 on-finished 这个包，当结束响应的时候此包能够执行一个回调来保存此请求的状态于 res

response helper 函数

koa有一个统一的响应函数位于 application.js 的末尾，专门负责处理 ctx.body ctx.status 来进行请求响应

// responses
if (Buffer.isBuffer(body)) return res.end(body);
if ('string' == typeof body) return res.end(body);
if (body instanceof Stream) return body.pipe(res);

// body: json
body = JSON.stringify(body);
if (!res.headersSent) {
  ctx.length = Buffer.byteLength(body);
}
res.end(body);

值得注意的是返回的body支持 Buffer string 流，以及最常见的 json

常见设计模式概要及其实践-TypeScript实现

Sun, 15 Oct 2017 00:00:00 +0000

若有不足或纰漏，欢迎指教

前言:

得益于TypeScript强大灵活的OOP语法，使得在js中使用经典且可靠的OOP设计模式变成了现实，虽然有的公司已经在大规模地使用TS进行中大型项目的开发，但极少有项目真正充分发挥了TS健全的OO语法优势，Java like 的OOP语法使其在思想上与Java的设计模式几乎无异，本文选取了一些常见且重要的设计模式进行提炼总结，避免探讨OOP与函数式编程孰优孰劣，模式的具体实现均采用TS进行编写，文末有彩蛋哦。

本文所有实战代码示例的GitHub仓库地址，欢迎Star

使用设计模式的意义：库与框架无法帮助我们将应用组织成容易了解，容易维护，具有弹性的架构，所以需要设计模式

基本设计原则：

封装变化
多用组合，少用继承
想到系统以后可能需要的变化以及应付变化的原则
针对接口编程，不针对实现编程
为了交互对象之间的松耦合设计而努力
松耦合的目的在于把对象依赖降到最低，增强系统的弹性
类应该对扩展开放，对修改关闭（开闭原则）
依赖抽象，不要依赖具体类
依赖反转原则：变量不可以持有具体类的引用，不要让类派生自具体类，不要覆盖基类中已实现的方法（子类应共享），不大会改变的对象可以违反，变化的对象可以使用工厂封装变化
最少知识原则：设计过程中不要让过多的类耦合在一起，使得尽可能少的类在一起交互
对象方法内只应调用对象本身的方法，或参数传进来对象的方法，或此方法创建的任何对象，或对象内的组件的方法（如果调用其它方法返回的是对象，不要调用其方法）
采用原则之前应全盘考虑所有因素
高层组件可以自行决定何时让低层组件参与，但低层组件不可以直接调用高层组件（在一些情况下也可以但绝不能形成环形依赖）
一个职责只指派给一个类，当它被设计成支持一组相关功能时，就具有了高内聚
上述所有的原则并非工程中的金科玉律，实际情况需要我们不断地平衡和取舍

策略模式 Strategy pattern

核心步骤是把类1中多变的不同种行为委托封装进一个个的行为类中，行为类1.2.3..将实现各自的同一接口的不同变种并以属性的形式存在于各个类1的相似类中，使算法变化独立于使用算法的客户

优点：

可以随时扩充新的行为
同一个类可以通过setter动态地改变它的行为

e.g: Strategy

观察者模式 Observer pattern

用于更好描述对象之间一对多的关系，当多个对象（观察者）依赖于一个对象（主题）的状态变化时，观察者模式可以帮助我们进行状态分发，将更新发送到各个观察者中，并使这两者松耦合

核心步骤：

主题类实现Observable接口，类中实现了对观察者的管理和对是否推送数据的判断，观察者类实现Observer接口，实现其中包含update方法供主题类调用，当注册新的观察者时，主题对象会将观察者对象存在观察者数组中，推送数据时遍历数组调用update方法，将数据传入其观察者对象中

e.g: Observer

装饰者模式 Decorator pattern

动态的赋予已有对象新的职责，比继承更具弹性，其中有使用到继承，但只是利用继承来达到类型匹配超类而不获得行为，行为来自于装饰者和基础组件或与其它装饰者的组合。

作为设计模式届的多米诺，每个新的被装饰者都不仅包含着上一个装饰者的状态而且还可以扩展自己的属性，通过共同的超类使得状态的共性得以保存且能够进行向上层级的链式调用，可以近似看做子类递归调用父类，使用此模式可以很好的替代继承

核心步骤：

被装饰类统一派生自一个超抽象类A获得其类型，装饰抽象类B继承A，并在构造函数中保存A类型的对象的所有状态，每一个新的装饰者包装上一次的被装饰者，被装饰类在被装饰之后仍可不断地被扩展

缺点：

客户代码不能依赖特殊类型，会出现许多小对象，过度使用会导致程序复杂

e.g: Decorator

工厂模式 Factory pattern

制造对象和解决耦合的好办法，严格来讲这并非一种模式而是一种编码习惯，将派生类的实例化封装在工厂类的静态方法中，抽象工厂方法可以让子类自行决定制造方式，在外部我们调用的抽象方法具有很大的弹性，实现可以不用绑定具体的类，这就得到了另外一个好处：使得超类和子类对象的代码解耦。而且能够将实例化延迟至子类中进行

核心要点

对需要弹性的方法使用抽象工厂方法来替代，想要使得产品可定制，可以将产品类定义成抽象类并提供一些默认的属性和方法或抽象方法，派生类可以自行进行覆盖重写或自行实现，不同的工厂类可以隐藏不同的产品的制造细节但却保留着相同的制作流程

e.g: Simple Factory

抽象工厂 Abstract Factory

不同的工厂类实现同一抽象工厂接口制造相似的产品，相似的产品再依赖于产品共同的接口来使得客户无须关心实际产出的具体产品就能使用

二者区别在于工厂方法委托子类来实例化对象，而抽象工厂建立了产品与客户的接口契约，两者都可以把客户从具体产品中解耦出来

e.g: Abstract Factory

单例模式 Singleton pattern

实例化唯一一个对象，提供一个全局访问点，所有设计模式中最简单但非常实用且用途广泛

核心要点：

把一个静态私有变量确立为唯一的实例，外部通过静态方法访问这个唯一的实例，并把构造函数设为私有

e.g: Singleton

命令模式 Command pattern

封装请求引入中间代理对象，将动作的请求者从动作的执行者中解耦出来，常用于工作队列或大型数据结构的操作记录以及事务处理

核心步骤：

具体任务执行细节封装于Command接口的execute方法的实现中，然后将实现接口的类的实例传递给它的客户，再由客户通过调用其execute方法来执行

e.g: Command

适配器模式 Adapter pattern

包装某些接口以实现不同的目的，转换接口使其能被其他的对象使用，改变接口符合客户的期望

核心要点：

对象适配器类实现目标接口并在其中调用待适配的对象的对应方法，使得在客户代码不变的前提下可以调用不同接口的对象

e.g: Adapter

外观模式 Facade pattern

使用外观类Facade简化接口，封装复杂的子系统，并暴露出更少的更简单的接口，打造更高层的功能，针对外观编程可以使得客户与子系统的组件解耦

核心要点：

构造Facade类的时候集合子系统的各个组件对象，暴露出的接口提供更直接更高层的操作，契合最少知识原则

e.g: Facade

模板方法模式 Template Method pattern

这种封装方式可以使得子类在任何时候都可以将自己挂载进运算里，模板方法定义了一个算法步骤，并允许子类为其中的部分步骤提供自己的实现

核心要点：

将相同的步骤抽离出来在抽象类中实现，不同的步骤在子类之中分别实现（父类中以抽象方法的形式存在），子类通过调用同一个模板方法去实现各自的功能（功能有部分不同，但单从模板方法中无法得知，因为被统一抽象了）。模板方法中可以加入钩子方法，提供默认的实现或留空以供子类进行覆盖，通过条件进行流程控制我们可以大大增加算法的灵活性，钩子方法通常是算法当中可选的一部分

常见应用场景:

对象排序的时候对象需要先实现一个比较方法

总结（踩蛋）

如果看到这里时，你仍然觉得这么多的模式使你头晕脑胀更别说应用的话，请收下这几枚硬干货：

计算机科学领域的任何问题, 都可以通过添加一个中间层来解决，几乎所有的设计模式都遵循了这个原则来应对变化增加弹性或进行扩展
抽象与复用是核心需求，摸石们都为了满足这两点而不断地努力着
没有完美的模式能够完美应对所有的变化

最后，希望你能够将模式多多应用到业务或编写框架中，尽最大努力编写出干净，可扩展，易维护的架构。

参考资料: 《HeadFirst设计模式中文版》2007年第一版

使用sftp搭建本地快速部署环境

Sun, 10 Sep 2017 00:00:00 +0000

准备

首先，我们要确保sshd也就是我们的ssh服务处于运行状态之中，下面以centos为例来讲解搭建的过程。

必要的包: openssh-clients openssh-server

运行下面的命令以确定我们的ssh服务处于active的状态中

$ systemctl status sshd

开始

新建一个用户(非root用户请加sudo)

$ adduser test

$ passwd test

设置密码，更新用户令牌信息，本地生成SSH密钥并将公钥放置于服务器，确保能从本地使用SSH登录远程主机

明确新用户的文件夹权限

$ chown root:root /../somepath/sftp
$ chmod 755 /../somepath/sftp

在sftp文件夹下创建uploads文件夹，所有上传的文件都会在里面，将拥有者设置为test用户

$ chown test:test /../somepath/sftp/uploads

将PasswordAuthentication设置为no并保存，确保不能用密码建立SSH连接并重启SSH服务

$ vi /etc/ssh/sshd_config
$ ...
$ systemctl restart sshd

现在在本地尝试使用sftp进行登录

sftp -i ~/.ssh/key test@ip_address

发现进入sftp即成功！

使用vscode配置快速部署环境

这里是用的是 ftp-sync 插件

安装完成之后按F1键

选择Ftp-sync: init

就可以在.vscode文件夹下找到ftp-sync.json文件

{
    "remotePath": "/../sftp/uploads/project",
    "host": "",	// ip地址
    "username": "test",
    "password": null,	// 留空，因为使用了更安全的sftp协议传输文件
    "port": 22,	// SSH端口
    "secure": true,
    "protocol": "sftp",
    "uploadOnSave": false,
    "passive": false,
    "debug": false,
    "privateKeyPath": "/Users/user/.ssh/key",  // 本地密钥的地址
    "passphrase": null,
    "ignore": [
        "\\.vscode",
        "\\.git",
        "\\.DS_Store",
        "\\node_modules",
        "\\test",
        "\\.travis.yml"		// 想要忽略上传的文件夹或文件
    ],
    "generatedFiles": {
        "uploadOnSave": false,
        "extensionsToInclude": [],
        "path": ""
    }
}

然后愉快地快速部署到服务器吧

F1

选择 Ftp-sync: Local To Remote

选择 full-sync，执行上传。大功告成！

注：如果是node项目的话可以使用pm2检测文件更改自动重启服务，一键更新线上代码！

参考：

https://www.digitalocean.com/community/tutorials/how-to-enable-sftp-without-shell-access-on-centos-7

用supertest进行API测试

Sun, 23 Apr 2017 00:00:00 +0000

在node开发中，写完了API接口之后，往往都要进行测试，现在常用的测试模块一般都是mocha和chai，然后我们应该有相配合的请求模块来帮助我们更好地完成断言的工作，今天要介绍的主角就是supertest

用过superagent的童鞋应该都知道，supertest的用法同样简洁优雅，本文环境基于Express，废话不说，上实战代码

GET 请求

const assert = require('chai').assert;
const request = require('supertest');
const should = require('should');
const app = require('../../app');
const _ = require('lodash');
// 将supertest设成request是习惯使然

// 断言
describe("get /", function() {
    // it描述了API的功能，预期的返回内容
    it("should respond with ....", function() {
        // 使用supertest进行GET请求，并验证其返回的状态码
        return request(app).get('/')
            .set('Accept', 'application/json')  //设置请求头
            .expect(200)    //预期的状态码
            .then(function(res) {
                assert.notEqual(_.findIndex(res.body, {
                    // 使用assert断言库进行断言，如果lodash找不到json中的最外层的键值对(找里面的话可以在body的基础上继续访问)
                    // 使用equal或者是to.include.keys('key')也是可以的
                    'key' : 'value'
                }), -1);
            })
    })
}

POST 请求

// 前面不再赘述，我们专注于supertest
return request(app).post('/search')
        .send({ key: 'value' })     // x-www-form-urlencoded
        .field('name', 'Jack')      // form-data
        .attach('avatar', 'test/fixtures/homeboy.jpg')  // post上传附件

PUT或DELETE请求

同理

request(app).del('/path')
request(app).put('/path')

python 语法基础

Tue, 11 Apr 2017 00:00:00 +0000

记录了python跟别的语言不一样的一些基础知识点

布尔类型

True

False

除法

/ 默认的除法是精确除法

// 才是通常的取商的整数部分

字符(类似C的ASCII码)

ord() 字符对应编码

chr() 编码转字符

'aaa'.encode('utf-8') 转成对应编码形式的bytes

'aaa'.decode('utf-8') 从bytes转成utf-8编码

格式化输出

r = 18.0555
'%.2f%%' %r
# '18.06%'

数据类型之list(类比数组)

获取list元素个数len(变量名)

访问元素下标为负表示都是第几个元素

末尾添加元素 vary.append(...)

插入指定位置 vary.insert(1, 'Jack')

末尾元素去除 vary.pop()

去除指定位置 vary.pop(2)

元素之间的数据类型可不同

数据类型之tuple元组

与list相比这样定义出来的数组内的元素是不可直接变的，数据更加安全

间接改变的原理：tuple是保持元素的指向不变，指向的内容是可能可变的，例如元素是list

t = ('A', 'B', 'C')

if语句

: 替代花括号块

elif 等价于其他语言的 else if

循环

for-in 循环 for x in ...:

continue 打破当前循环进入下一次循环

break 退出循环体

dict 键值对

d = {'A':11,'B':22,'C':33}
d['B']
# 22

找不到key时会报错，所以查key之前要判断一下key in d的返回值再查找

或者

d.get('B', -1) 第二个参数指定了找不到时返回的值

dict 中的key不可变

删除 d.pop(key)

set key的集合

初始化需传入一个list，传入的元素不能有重复的

s = set([5,5,6,7,7,6,7])
# {5, 6, 7}

添加 add(key)

删除 remove(key)

字符串对象

str.remove('a', 'A')将a替换成A但是方法会返回一个新的串，原来的str不可变！

基本函数

abs()

max() 可以放任意个参数只返回最大

a = abs 给abs函数引用发给a，调用a()效果一样

类型转换

int(要转换的变量)

其他类似

定义函数

def 替代function

缩进体置空

pass

函数返回值

居然可以有多个!! 我的三观…

def goBack(x,y)
	return x,y

a,b = goBack(1,2)

原因：返回的是tuple

类型检查

def goBack(x,y)
	if isinstance(x, (int, float)):
		return x,y
# 允许int和float类型

参数

def power(x, n=2):
# n默认值为2

默认参数必须指向不变对象

参数可以是 list 或者 tuble，利用可变参数

可变参数 def calc(*numbers): 多参数自动组装成tuple

关键字参数 def person(name, age, **kw): 方便扩展函数的参数

参数定义的顺序必须是：必选参数、默认参数、可变参数、命名关键字参数和关键字参数

尾递归优化递归函数

指在函数返回的时候，调用自身本身，并且，return语句不能包含表达式

注意：标准解释器并不支持这种用法

机器学习的常用概念

Sat, 08 Apr 2017 00:00:00 +0000

特征(属性)

通常是训练样本集的列，可看作是每个列的列名，比如区分鸟的品种可以用体重，后背颜色此类的特征来加以区分

特征实例

某一特征列其中的数据

特征的种类

数值型
二值型(类似布尔型)
枚举类型(颜色色值)

训练集

训练集是用于训练机器学习算法的数据样本集合

训练样本

样本集的每一行就是一个训练样本

目标变量

机器学习算法的预测结果

分类:

分类算法中，通常为标称型，目标变量称为类别
回归算法中，通常为连续型

训练样本集前必须要确定目标变量的值，比如根据鸟的身高，体重，颜色这些特征可以具体确定鸟的品种，品种就是目标变量，而品种的值就是具体的品种名称，也就是目标变量的值

知识表示

指展示机器分类的结果的工作

形式包括：规则集 概率分布 训练样本集中的实例

Why?

以便机器学习算法发现特征与目标变量的关系

机器学习的主要任务就是分类

将实例数据划分到合适的分类中

分类的基本流程：

得到全部特征信息
算法训练(学习如何分类)
测试机器学习算法的效果

如何测试算法的效果？

为了测试效果，通常会使用两套独立的样本集：训练数据 和 测试数据

机器学习另外一个重要的任务：回归

主要用于预测数值型数据

程序开始运行:

训练样本集提供目标变量 => 输入到算法 => 训练完成 => 输入测试数据(不包含目标变量) => 比较测试结果与实际目标变量的差别(回归拟合) => 得出算法的实际精确度

监督学习与无监督学习

监督学习指算法知道预测什么，也就是有明确的目标

回归和分类都是属于监督学习

与监督学习相比，无监督学习没有目标值

非监督学习

作用：

减少数据特征的维度

聚类(分析)

把相似的对象通过静态分类的方法分成不同组别或者更多的子集，相当于是把一个训练集分成了多个训练集，每个新训练集中的数据的特征相似

密度估计

指寻找描述数据统计值的过程，可以理解为要得到关于描述数据的 频率分布直方图，降低特征维度，使其更直观

浅谈算法的选择

以目的为导向：根据要完成的任务，选择监督学习的或者是非监督学习的算法
以数据来源为导向：需要分析或收集的数据是什么

开发机器学习应用程序的大概步骤

收集数据
准备输入数据
分析输入数据(人工)
训练算法(机器学习)
测试算法
使用算法

Linux WEB基础学习笔记

Wed, 29 Mar 2017 00:00:00 +0000

系统版本选择

根据不同发行版本的特性

red hat 企业（付费）

ubuntu 跨设备：服务器，台式，笔记本，嵌入式设备

debian 稳定可靠，但更新周期长

Mint 台式机用户并支持专利性媒体

Core OS 容器化应用程序的计算机集群建设

系统路径

pwd

返回当前的目录位置

/表示系统的根目录，可以进入的最高位置

所有Linux系统中都可以找到/home这样的目录，除少数例外情况，home目录可以容纳每个用户的所有主目录

ls -a

显示所有文件包括隐藏文件

任何前缀是.的文件都是会被系统隐藏的

ls -al

以长格式打印所有文件信息

drwxr-xr-x 4 root root 4096 Jul 2 21:00 ..

首字符为d，代表这个结果是目录，-代表文件

后面的每三个分割开来看，分别对应所有者owner，组group，所有人everyone

分别是读，写和是否为可执行文件对应字母为r,w,x

后面紧接着就是所有者和组，linux在创建用户的时候会自动创建相同名字的组

根目录常用文件夹

etc 存储配置文件，配置服务器的时候就会修改其中的文件

var 存储可变的文件，里面的文件一般会随着时间的推移而变大，可找到系统日志和应用程序日志

bin 用于存储可执行的二进制文件，所有用户都可以访问，一般在启动时和系统维护进程中用到

sbin 与bin类似除了其中的可执行文件只能被root用户用于系统管理和维护

lib 存储支持系统中存储的二进制文件的库文件

usr 用于存储用户程序

命令的运行过程

输入ls
系统在$path中按顺序寻找路径下名称为ls的可执行文件
找到在bin中

Linux 安全

使用最少权限

超级用户root

通常情况下，我们禁用root的可远程访问权限，用自己创建的身份登录，然后通过其他命令，我们也可以以root身份运行超级用户的命令，使服务器在用户名及密码未知的情况下被攻破的可能性得到降低

普通用户可以在命令前面加上sudo来以root的身份运行命令，其中的好处是会出现警告，提前预知危险

使用包管理软件

所有可用的程序包来源都会列在/etc/apt/sources.list文件中

sudo apt-get update

更新仓库源，并不会对系统进行更改

真正升级包要使用

sudo apt-get upgrade

包finger的使用

用途：用于查询用户的各种信息打印成易于阅读的格式

Command

finger
finger 用户名

用户信息大部分都存储在/etc/passwd中，用cat打开如下

文件中的每一行代表一个单独的用户，每个条目包含数个由冒号隔开的字段

第一个字段是指用户名，第二个用于存储加密的密码，第三和第四字段分别存储用户的ID和组ID，第五个字段用于存储更多说明，最后两个是用户的主目录和用户默认的shell，可以看到，linux的root用户的组ID和用户ID都是0

用户权限

创建新用户

sudo adduser student

远程SSH登录

ssh student@127.0.0.1 -p 2222

用户名@IP地址

-p 端口号

赋予sudo权限

有sudo权限的用户登录执行

cat /etc/sudoers

ubuntu中有sudo权限的用户都在/etc/sudoers.d中

可使用已有的用户进行cp成用户名，然后用nano进行编辑

将名字改为用户名保存

强制下次登录时重置密码

sudo passwd -e 用户名

基于密钥的身份验证

公共密钥加密

服务器发送任意消息至客户端，客户端用私有密钥进行加密，再将加密后的消息发送给服务器，服务器用公共密钥进行解密，如果与服务器发送的值相等，那么通过

私有密钥要自己保留

在本地生成密钥对

ssh-keygen

为密钥添加密码

生成的.pub文件就是放在服务器上用于密码身份验证的文件

将公钥放在服务器上

mkdir .ssh
touch .ssh/authorized_keys

拷贝本地的密钥内容至服务器更创建的文件中，并为文件设置权限

chmod 700 .ssh
chmod 644 .ssh/authorized_keys

使用ssh密钥登录

ssh student@127.0.0.1 -p 2222 -i ~/.ssh/密钥名称

禁用密码登录

编辑SSHD配置文件

SSHD: 运行于服务器上监听SSH连接的服务

sudo nano /etc/ssh/sshd_config

将PasswordAuthentication设置为no保存

然后重启服务，让它重新读取配置文件

sudo service ssh restart

文件权限

数字与权限的关系

r = 4

w = 2

x = 1

无需权限，值为0

加在一起即为要进行应用的全部权限数量（注意只是对于一种用户）

系统需要一次处理三个权限，以一次设置用户，组和所有人的权限

更改文件权限

chmod 数字 文件夹或文件 //改权限
chown 所有者 文件 //更改所有者
chgrp 组名 文件名 //更改组

防火墙

端口

每个应用程序都会被分配端口来处理各自的请求

常见端口如下图

通过防火墙，可以控制服务器允许哪个端口接受请求

只开放让应用程序行使正常功能的端口

ubuntu ufw 防火墙

激活ufw

sudo ufw status //查看状态

写入防火墙规则并开启防火墙

sudo ufw default deny incoming  //阻止所有 default allow outgoing 允许所有
sudo ufw allow ssh	//允许开放SSH连接端口
sudo ufw allow www 	//允许HTTP请求
sudo ufw enable		//开启防火墙

Express下多次callback引发的问题

Thu, 23 Mar 2017 00:00:00 +0000

错误结果

Error: Can’t render headers after they are sent to the client.

错误：当响应头被发回客户端时不能被正确渲染！

出现场景

Express环境下使用mongoose model 进行模糊查询时，需要用ORM进行至少一次至多两次的查询，查询用的都是Promise进行的异步操作

问题排查

响应头的设置出现了冲突
是res.send(docs)出错
调试时移除了其中一个Promise查询，错误消失
问题出在Promise上

问题分析

为什么连续的两个Promise回调会最终导致响应头渲染冲突?

渲染冲突出现在错误的顶部，跟错误抛出的顺序有关，这与Express自带的res对象有关，而res又继承自node.js原生的http.ServerResponse 类，在res调用res.writeHead(statusCode)写入响应头的状态码之前，我们可以尽情的写入响应头的头信息，在一个res.send(docs)中，应该包含着以下几步，有的是exprerss自己的，有的则是属于node原生http模块的

按以下顺序开始运行:

res.writeContinue()

res.statusCode = 404

res.setHeader(name, value)

res.getHeader(name)

res.removeHeader(name)

res.header(key[, val]) (Express only)

res.charset = ‘utf-8’ (Express only)

res.contentType(type) (Express only)

res.send([body]) (Express only)

最后我们的查询数据是以响应内容中的body的形式返回给客户端的，当要进行send的时候，node自带的函数就会先运行，当然运行第一个Promise的时候是没有问题的，问题在于:send本身并不能中断当前执行的任务，只要还没有return，代码仍然会继续运行，这也恰恰印证了node的异步非阻塞IO的特性，即便是第一个Promise执行时，并不会阻塞第二个Promise的继续执行，如果第一个Promise的res.send已经执行，当第二个Promise被执行时，执行至第三步，也就是设置响应头的时候原先的响应头信息依然存在，触犯了**node**中不能重复设置响应头信息的规定，所以node先抛错，这一切看起来也就顺其自然了

All in all 解决方案呢？

避免使用多次send,多次设置响应头就会出现此错误
谨慎使用异步Promise，可以考虑Promise嵌套**（推荐）**
send之前记得加上return让后面的代码不会运行，但这个方法不好难以控制，当异步操作写在一起的时候，谁知道会是哪一个家伙先结束呢？

夹杂数字字母大小写的字符串按字典排序方法

Fri, 04 Nov 2016 00:00:00 +0000

核心步骤概要

过滤

过滤数字等特殊符号，只剩下字母

这里要用到String类自带的replaceAll方法以及表达式进行过滤

分割

将字符串进行单字符分割

这里要用到String类自带的substring方法

排序

将分割得到的单字符String数组进行忽略大小写的排序

这里要用到Arrays类中的sort方法

关键代码演示

写在前面

因为输入的行数和字符串内容任意，所以将每行的字符串直接add入Java的ArrayList动态数组中，接着再装入用length初始化的String字符串数组newArray中，从而避免了从Object类型进行强制转换String[]的风险

字符串过滤演示

for (int i=0;i <elementIndex;i++)
newArray[i] = newArray[i].replaceAll("\\d+","");
//这里演示的是去除数字

拓展：

.replaceAll(“转义符+正则表达式”,“要替换成的字符”);

字符串分割演示

for(int k=0;k<newArray[number].length();k++)
sortArray[k] = newArray[number].substring(k,k+1);
//用一个for循环一次切割一个字符并添加入sortArray中

拓展：

String类常用方法

方法用途	定义
起止字符分割字符串	substring(int beginIndex,int endIndex)
将某字符用作分隔符	split(String regex) return String[]
转成大写字母	toUpperCase()
转成小写字母	toLowerCase()
去掉开始和末尾的空格	trim() return a string
比较字符串	boolean equals(Object anObject)

单字符String数组排序演示

Arrays.sort(sortArray,String.CASE_INSENSITIVE_ORDER);
//不分大小写进行排序

拓展：

Arrays类常用方法

方法用途	定义
将数组排序	sort()
查找数组中的值	binarySearch(object[ ], object key) *先用sort()排序后用
复制数组	int[] copyOf(int[] original,int newLength)
数组中值的替换	fill(int[] a,int val)
待续….

完整代码demo演示

/**
 * Created by Tecker on 2016/6/21.
 */
import java.util.*;

public class UsingArrayList {
    public static void main(String[] args){
        int elementIndex = 1;
        Scanner inputElement = new Scanner(System.in);
        ArrayList elementlist = new ArrayList();
        boolean inputOver = false;
        System.out.printf("请任意输入N行N个字符串\n");
        System.out.printf("当输入inputOver时结束\n");

        do {
            System.out.printf("输入第" + elementIndex + "个字符串\n");
            System.out.printf(">>");
            String input = inputElement.nextLine();
            if (input.equals("inputOver")){
                inputOver = true;
                System.out.println("输入完毕！");
            }
            else {
                elementlist.add(input);
                elementIndex++;
            }
        }while (inputOver == false);      //用do-while语句加上if判断来控制输入N行夹杂数字大小写的字符串
        elementIndex = elementIndex - 1;
        System.out.printf("排序前:\n");
        String[] newArray = new String[elementIndex];
        for (int k=0;k <elementIndex;k++)
            System.out.printf(">> " + elementlist.get(k) + "\n");
        for (int index=0;index <elementIndex;index++)
            newArray[index] = elementlist.get(index).toString();
        for (int i=0;i <elementIndex;i++)
            newArray[i] = newArray[i].replaceAll("\\d+","");
        for (String element : newArray)
            System.out.printf(element +"\n");
        System.out.println("排序后\n");
        for (int listIndex=0;listIndex <newArray.length;listIndex++){
            sortArrays(listIndex,newArray);
        }


    }
    public static void sortArrays(int number,String[] newArray){
        String[] sortArray = new String[newArray[number].length()];
        for(int k=0;k<newArray[number].length();k++){
            sortArray[k] = newArray[number].substring(k,k+1);
        }
        Arrays.sort(sortArray,String.CASE_INSENSITIVE_ORDER);
        String finalString = ">>";
        for (int j=0;j<sortArray.length;j++){
            finalString = finalString.concat(sortArray[j]);
        }
        System.out.println(finalString);
    }

}

游壳说 – 托克的诺亚方舟

用上这4个原则，为AI编程提效

你的 AI 为什么总在重复犯错

从一个真实案例说起

记忆系统无法解决团队协作问题

不再滥用 /init

Karpathy 的 4 条铁律

为什么这 4 条比 20 条更有效

从 4 条到 12 条：什么时候扩展

项目规则不要写成百科

根 CLAUDE.md 更像入职说明

什么时候更新

立刻开始

致精神股东们的信2026

前言

互联网世界的变革

AI智能体生产循环机制

消费侧的变革

文字的力量

展望未来

Docker 容器与容器云读书笔记

Namespace

UTC namespace

IPC namespace

PID namespace

Docker 原理剖析

Namespaces

网络

libnetwork

挂载点

CGroups

UnionFS

正则表达式快速入门

同一匹配目的但实现有区别

匹配多个

大小写

匹配任意字符

匹配一组字符

元字符

匹配特定字符类别

匹配空白字符

匹配多个字符

匹配0个或1个

限定匹配的重复次数

贪婪型和懒惰型元字符

位置匹配

边界限定符

分行匹配模式

子表达式

子表达式嵌套

回溯引用

使用回溯引用进行替换

前后查找

嵌入条件

回溯引用条件

前后查找条件

上下文工程中提示词编写的原则和技巧

提示词编写的核心原则：清晰性与极简主义

极度清晰和直接的语言

追求最小化信息集合

关键技巧：定位“正确的高度”（The Right Altitude）

失败模式一：过于僵化（硬编码的复杂逻辑）

失败模式二：过于笼统（模糊的指导）

“正确的高度”的提示词

结构化提示：利用标记增强 Agent 可读性

少样本提示（Few-shot Prompting）的精心策展

编写高效工具的最佳实践指南(精华版)

简介

核心方法论：构建、评估与协作优化

编写高效工具的关键原则

展望

提示词技巧之元提示

背景

什么是元提示词？

常见的元提示词模版

总结

CGO封装CPP库的一些最佳实践

背景

如非必要，勿用CGO

C ABI接口封装遵循最小化原则

不再滥用 `/init`