签名版

签名版的价格和上一版保持一致，依然是 109。付款方式和详细说明可以访问预售页面查看：

https://helloflask.com/book/4/signed/

签名版除了送 2 张 Flask 贴纸，还会额外送一张我的名片，可以用来当书签或者飞着玩。具体发货时间取决于正式发售时间，虽然不能完全保证，但我会尽量让签名书第一批发出。

新书名

你也许好奇为什么要换一个新书名，而不是作为第 2 版出版，即《Flask Web 开发实战（第 2 版）》。我设想了一些合理解释：因为内容变动比较多，换个更贴切的书名；在副书名里加一个 Python 关键字，更容易被别人搜索到……但背后实际的乌龙是：管理书号的工作人员在录入系统时打错了名字，把《Flask Web 开发实战》写成了《Flash Web 开发实战》。

按照出版规定，如果我想作为原书第 2 版来出版，那么新书名就只能叫《Flash Web 开发实战（第 2 版）》了。诸位应该也不想学 Flash Web 吧？

面向 Flask 2.x 的旧版本当然没法作为先导材料，所以断断续续花了 26 个小时完成了第 4 版的更新。新版本主要有下面这些变动：

• 优化全书的内容和措辞
• 增加对 uv 的介绍
• 升级到 SQLAlchemy 2.x
• 针对 Flask 3.1.x 进行内容更新
• Python 支持版本调整为 3.9+
• 增加对蓝本、工厂函数的介绍

另外正式加了一章介绍为什么以及如何为本书付费，取代了主页上自愿点击的「付费支持￥10」按钮。考虑到整本书内容完全公开，所以没法阻止读者逃票，但至少我已经克服了「伸手要钱」的羞耻。对于在工作之外挤出的这些时间，我需要一些正反馈。这样可以让自己更认真维护下去，也不会产生怨念。不仅是获得收入，有时还会收到读者的附言感谢，这给我的生活里带来了很多随机的开心时刻。

写新版本的过程中有时也会想，现在跟 AI 说一句「帮我用 Flask 写一个 Watchlist 程序」就大概能实现的程序，还有人愿意来读教程吗？我想至少，在通过教程来学习编程可以让你说一句「我真厉害」，而不仅仅是一句「AI 真厉害」。

另外这个教程最早是在 2019 年发布的，六年过去了，部署章节介绍的 PythonAnywhere 的 UI 和功能基本没有任何改变。我只需要更新 Python 版本选择那个页面的图片，其他部分不需要任何改动。有一种值得托付终生的感觉。希望可以做出来有这样品质的产品和作品。

最后附上相关链接：

• 主页：https://helloflask.com/book/3
• 阅读：https://tutorial.helloflask.com/
• 书稿更新 PR：https://github.com/helloflask/flask-tutorial/pull/38
• 示例程序更新 PR：https://github.com/helloflask/watchlist/pull/21

七月我们突破了屏幕的限制，在戴尔五角场办公室举办了第一次线下代码厨房开源松。而这一次开源松 Sprint 6 我打算在 11 月 23 日举办的 PyCon China 2024 大会里办一场开源松。没错，一场面向 Python 爱好者的开源松！

开源松！？

开源松（Song of Open Source）是代码厨房社区自造的词语，可以大概理解为开源黑客松，但是又不必那么 hack。只是一场开源爱好者互相交流和共同参与开源项目的聚会活动。我们希望借助这个活动来鼓励和帮助大家参与开源项目、推动开源项目发展、孵化新的项目 idea。

如果你从来都没有参与过开源项目的话，这次活动也许会是你开源之路的第一步。你会认识其他喜欢编程和开源的朋友，和开源项目维护者们交流，顺便提交第一个开源贡献。

PyCon China 2024 x 代码厨房开源松

开源松活动在大会下午开始，你可以在现场找到开源松会场指引标识，或者到代码厨房社区展台询问。如果打算参加活动，记得在报名大会时勾选相应的选项。会场内会设置三个活动区域：

• 养成区：给没有参加过开源项目的新手提供科普和指导
• 发电区：用爱发电的地方
• 休息区：代码写累了？来和其他开源爱好者聊天吧

顺便也欢迎来代码厨房展台玩。我们为还没开始工作、或者刚刚被裁的朋友准备了「Python 八股文面试题挑战」……通过挑战的话可以体验现场拿 offer 的感觉。

有哪些项目可以参与？

在其他项目报名之前，我们已经准备了两个代码厨房社区项目：

• FineWeather：一个 Vuejs+Python 实现的网络相册

不管你喜不喜欢拍照，肯定有一堆照片存在某个地方。有没有想过摆脱商业公司的限制，自己部署一个在线相册？放上自己最喜欢的照片，自己的数据自己管理。一起来打造一个完美的开源相册程序吧。

下面是项目作者 Allen 部署的相册实例：

• APIFlask：Python Web API 框架

新增项目：

• PDM – Python 包和依赖管理器
• pyecharts – Python ECharts Plotting Library
• UtilMeta – Python 渐进式元框架

基于 Flask 实现的 Web API 框架，集成了 marshmallow、webargs 等项目来让 Web API 开发更加简单。我们在计划项目的 3.0 版本，有很多有用的功能可以加入。完成了大半的文档翻译项目也等待一个人来再推进一步。

如果你有自己的 Python 开源项目，欢迎报名参与！作为项目维护者，你需要完成这些事情：

• 准备三个不同难度等级的任务
• 在现场介绍项目和任务
• 指导参与者完成任务
• 准备小奖品（可选）

报名方式：在代码厨房社区置顶贴留言，或是通过下面的表单报名：

https://jsj.top/f/CscvKZ

你需要准备些什么？

除了了解 Git 基本用法，你还要会一点 Python。有一台充电器还找得到的笔记本电脑。还有一点点的开源热情。

如果你不仅仅想要来做开源项目，那么可以带一点其他的东西来。比如一个关于你自己项目或其他经验的五分钟分享、新项目的 idea……尽管自由发挥。 如果你有其他想法和建议，欢迎留言。

开源松/大会报名

这次开源松将在 PyCon China 2024 内举办，因此报名大会即可参与：

https://hdxu.cn/g77s

Flask！Flask！你怎么了？Flask~Flask~你不能死呀！我跟你相依为命、同甘共苦了这么多年，何况我的书还没有写完，想不到今天白发人送黑发人……

咳咳，说回正题，2021 年我写过一篇《请不要把 Flask 和 FastAPI 放到一起比较》。不是同一个等级的框架拿到一起比较没有意义。这篇《Flask 已死，FastAPI 是未来》从一开始的标题就是错的。

除了比较上的问题，上一篇文章里最后提的问题现在有答案了吗？

各种对比文章贴出来的 hello world benchmark 对于开发生产应用来说有多大的意义？这里的 benchmark 背后有没有任何的 hacky？异步是否等同于高性能还是要看情况？框架本身的性能在一个请求处理流程中占多大的影响？asyncio 的生态怎么样？

同时我也指出了一些 FastAPI 的问题——现在 FastAPI 营销至上的项目运作方式改变了吗？

从长远看这些大都是一些临时问题，而且 FastAPI 作者已经开始全职开发开源项目，这些问题在未来应该都会慢慢得到改善。指出这些是希望更多的人可以客观看待 FastAPI，吹捧并不能让一个东西变得更好，参与开发、介绍用法和回答社区提问是比盲目吹捧更有意义的事情。我当然期待 FastAPI 能够越来越好，也期待看到有更多优秀的 Python 框架出现，但我不喜欢过度炒作、盲目的吹捧和错误的对比。

如果一个人即没有深入了解 Flask，也对 FastAPI 的整体状况一知半解，然后突然跳出来写了一篇《Flask 已死，FastAPI 是未来》，他的目的是什么？炒作啊，朋友。标题党也就罢了，到处都是逻辑漏洞和事实错误这也行？

精彩片段赏析

前两天在 Twitter 上对这篇文章发了一点想法。大概是我的语言能力退化，导致很多人没看懂我的反讽和调侃……所以还是好好说话，摘评几条原文的内容：

其实我这篇文章，也可以叫做「Django和Flask之死」，但是在框架应用场景角度来说Flask和FastAPI对比更合适，而Django直接和FastAPI相比有一些差别。在一些商业场景(例如CMS)Django依然是首选，而Flask(甚至FastAPI)看起来更像个「玩具」，所以Django短时间不会被取代(Flask这些年不是也是没取代的了嘛)。
Django REST Framework(DRF)
Django主旨是为了在后端生成 HTML，而不是创建现代前端（如 React、Vue.js ）或与其通信的其他系统使用的 API。所以FastAPI其实和Django REST Framework直接对标，它们主要场景都是构建 Web API，但是名字上也可以看出来，DRF还是依托于Django框架，所以缺点一样。

既然作者能看出来 Django 和 FastAPI 有差别，也了解「FastAPI其实和Django REST Framework直接对标」，那么就看不出来 Flask 和 FastAPI 在框架应用场景角度有差别？所以为什么不用 APIFlask 这种和 FastAPI 对标的框架，而是挑了 Flask？

Flask本来的优点是灵活性和极简主义，但这意味着很多很多组件需要自己造，这个要不然需要公司够大专门有开发者开发和维护，要不然得个人能力极强，否则插件很难达到生产级别，这就造成Flask的第三方插件质量层次不齐，且无法保证长期维护。就像我上面说的那些库，现在来看，其中已经很多不再维护了。

这点蛮中肯，Flask 扩展的质量和维护状态确实参差不齐，这也是为什么我要发起濒危 Flask 扩展拯救计划并创建这个 Flask 扩展状态监控项目。那请问 FastAPI 呢？首先 FastAPI 是否有这么多「FastAPI 扩展」可用？其次 FastAPI 的第三方插件就不会出现这些问题？说到底这是所有开源项目和社区生态都会遇到的问题。

所以即便是今天，你想用Flask构建一个API服务，还是要东拼西凑各个组件，其中某些组件有些没及时更新的地方要自己动手解决，这对于老手来说还好，对于新人来说很痛苦，尤其是你想要应用现在最新的实践方案和理念，只能望而兴叹。

首先作者了解 Flask 和 FastAPI 相比，后者的主要场景是「主要场景都是构建 Web API」，接着又说 Flask 生态构建 API 需要东拼西凑。听起来不太对劲？

另外 Flask 生态中类似 FastAPI 这种提供 API 整体解决方案的框架都被作者忽略了？随便列几个：

• APIFairy
• APIFlask
• Connexion
• Eve
• Flask-RESTX
• Flask-Smorest
• Flask-Rebar
• SpecTree

东拼西凑就一定是缺点？不熟悉这些工具的人选择打包方案，熟悉的人选择自己组装，这有什么问题吗？

这个时候Flask并不想接受改变，社区迟迟的不加入aio的支持，另外Flask原作者也去写rust了，把项目交给了2个维护者（现在只剩一个人了)。

到这里文章就开始有些不对劲了，喜剧/戏剧效果逐渐增加……Flask 开始被拟人化了。Flask 是谁？是谁要求改变？Flask 说了啥表示不想改变？

Flask 作者把项目交给了 2 个维护者？现在只剩一个人了？！Flask 真的好惨……可是这些事情都是什么时候发生的？虽然我最近两年开始工作已经没怎么给 Flask 提交代码，不知道哪天被踢出群聊。但是至少我从 18 年到现在一直是 Flask 的维护者，这些事情我怎么一点都不知道？

在Flask的那个时代，代码执行是单线程、同步的，这意味着要依次处理请求，前一个请求完成前，其他请求消耗在等待 I/O 操作上。而asyncio是最好的解决方案，它让I/O成为异步操作，无需等待任务完成即可获取任务结果并继续处理其他任务请求。

好奇 Flask 的那个时代是哪个时代呀？听起来像是妈妈在讲小时候的故事呢。Flask 2.0 已经添加了有限的 async 支持。Quart （Flask 的 ASGI 实现）已经合并到 pallets 组织，作者正在推动 ASGI 支持的 Flask。这些都是这个时代的 Flask 在发生的事情哦。

而FastAPI天生支持并发和异步代码，代码写对了就可以在效率上达到极致，所以它被认为是目前最快的Python框架，效率和NodeJS或Go接近。当速度和性能至关重要时，FastAPI 是最佳选择。

嗯，这个我无从反驳。你说快就是快，宇宙最快 Web 框架。

另外由于集成了Pydantic，所以非常容易在项目中添加ORM（如SQLAlchemy），从请求中获得的对象可以直接传递到数据库，因为已经做过数据验证。反之亦然，可以将从数据库获取的对象直接返回。
相对的，Flask这方面的缺失的。

完蛋，Pydantic 对 Flask 发起了单方面安装制裁。当你在 Flask 项目里试图引入 Pydantic 的时候，就会出现安装错误“Warnning: Pydantic is strictly forbidden to installed into a Flask project. Your behavior has been reported to PAFAFC (Pydantic and FastAPI and friends Committee).”

再补充一点。FastAPI无论看项目名字还是介绍都能感觉出来它是用于构建API服务的，事实上FastAPI自己的核心代码也确实是这样的，可以说它不是一个传统的、完全自己实现的框架，它更像是一个集各家之长的框架，从一个空壳开始，把需要的、适合的组件组装起来。例如它没有模版引擎，如果你确实需要用它实现一个web应用要渲染模版，你可以再组合你想要的选择，当然还可以用Starlette内置的Jinja2（是的，也是Flask内置的）。

作者对于 Flask 和 FastAPI 两者定位不同的认识真是越来越清晰了呢。不过「组合我想要的选择」不就变成前面说的 Flask 那样东拼西凑了嘛，不好。还有就是 FastAPI 为啥要在介绍模板引擎的文档里让我安装 Jinja2 呢？看来「相对的，FastAPI这方面是缺失的」。

上面提的是FastAPI的优势，但是也不能说明Flask已死，我为什么会这么觉得呢? 主要还是看开发者和用户的人气。

重头戏来了，下面终于到了对于「Flask 之死」的凄惨景观的详细描写（注：这几点后来作者看到了我在 Twitter 上发的东西又自己做了补充和修改。这里我引用的是原文）。

1. 社区活跃度。例如项目的Issue和Pull Request数量，Flask都是个位数，和FastAPI相比根本不是一个水平。这其实侧面证明项目不再活跃，因为如果活跃的话，老的用户会有更多需求，它们不来说明已经离开，而新的用户意味着有各种问题，文档即便足够全，其实我们要知道还是会有很多用户来提问和贡献代码的，没有就说明用得少。

如果你经常参与开源项目或是自己开发了开源项目，通常会了解到，一个流行的项目想要把所有的 issue 和 pull request 都处理掉是很难的事情。而 Flask 能做到这一点反而是维护团队的努力尽责和项目本身足够成熟的体现：

以及对 issue 和 pull request 快速响应的体现：

如果你想知道有多少人在用 Flask 和 FastAPI，有两个参考数据，一个是 GitHub 上开源项目的用户数量统计。这些可以在两个项目的 GitHub 主页直接看到。

FastAPI：

Flask：

另一个数据是 PyPI 下载量，这个可以在 PyPI Download Stats 上看到。

FastAPI：

Flask：

另一方面，不同的项目对 issue 的使用策略是不同的。有的使用自己的 issue tracker，有些鼓励用户来提问。Issue 和 pull requests 不仅不能用来表示项目活跃度，过多的数量反而能说明一个项目的维护状况堪忧。堆积的 PR 对于用户和开发者来说都是灾难。以 FastAPI 为例，你看看现在的 PR 列表里都是什么？项目不如改名叫「FastAPI 文档大全」好了。你觉得这样会让提交代码贡献，修复 bug 的人有很好的体验？

FastAPI 有不少 issue 在建议作者创建开发团队，摆脱当前这种低效的维护模式。类似的抱怨有很多，我不想去翻历史，这里仅以置顶 issue 里的一则回复举例：

评论中提到的是这个 PR。一个 bug 在 2022 年就有人试图修复，但是到现在都没有被处理。而且报告相关 bug 的 issue 已经被转换成讨论。最后一条是用户在建议把这个讨论转换回 issue：

没错，FastAPI 本来有几百个 issue（好活跃，对吧），某个时间点被批量转换为讨论，谁知道里面有多少是没有被处理的 bug report。谁知道这 646 个 PR 里有多少是需要被优先处理的 PR。我在 2020 年也提议把文档翻译放到单独的仓库，后来这个 issue 也被转成讨论了。到现在贡献者依然被这个问题困扰：

2. 讨论度。也就是博客文章，Stackoverflow等网站咨询和讨论的热度，其实可以感受到，已经没什么人写Flask相关的内容了。

作者写文章是可以随口就来的？博客文章不好统计，那么以 Stack Overflow 来看。抛开问题总数量，因为两个项目创建时间不同。但就提问频率，以上次发推文和现在两次截图的数据来看，和 Flask 相关的问题都创建的更频繁。

FastAPI：

Flask：

3. 开发迭代的频率。翻一下commits，可以看到Flask只有一个维护者会偶尔修修bug，没有什么大的功能特性开发。

开发迭代的频率和活跃度也是作者强行建立的联系，不过结合 FastAPI 的运作方式，两位作者倒也是「双向奔赴」了。「偶尔修修bug，没有什么大的功能特性开发」有什么问题吗？这就是维护者应该做的事情，大的功能特性又不是每天都有。而且作者是不是没有看 FastAPI 的 commits 历史？你肯定猜不到三千多个 commits 里有一千多是 bot 在更新 changelog。再猜猜 FastAPI 最新一个 release 都有哪些新功能？11 个改动里有 5 个是在更新 README 上的赞助商列表哦：

4. 灵魂人物的影响力。Flask的灵魂人物，也就是项目的发起人其实早就不再参与项目了，搜一下项目贡献记录可以看到Armin Ronacher上次参与开发已经是6年前了。

这条实在不知道说什么好。我创建了项目我就得绑死在项目上直到生命最后一刻是吗？引用一下我在 Twitter 上的回复：

开源项目一定不要创建 GitHub org，项目再流行也要放在自己的账号下。不要成立什么开发团队，PR 要自己慢慢 review，用户抱怨多了，你自然知道哪个 PR 比较重要。还有就是用自己的账号或头像来设置 bot，这样即使你哪天兴趣转移了，用户会以为你一直在参与。斯人已去，灵魂犹在。

我真的佩服 FastAPI 作者这一招用自己的账号来作为 bot，用户以为你在活跃，而这个 PR 哪天能够被 merge 还要多烧几炷香：

一边说自己忙得不行，一边又坚持把项目放在自己个人账号下，坚持自己 review PR。这就是灵魂人物？

后记

终于写完了。没想到只是偶然在一台没有屏蔽推荐首页的电脑上打开了知乎，最后要浪费这么多时间和精力。我想肯定会有人看了开头就急着评论，说「FastAPI 如何好用」或是「Flask 如何不好用」甚至是「Python 不如 XXX」。这些都是离题的讨论，我不完全否认这些观点，也并没有谈及这些。这篇文章只有两个目的：

• 强调不应该把两者放到一起比较
• 指出那篇「引战文」中的错误观点和事实偏差，顺便指出一些 FastAPI 的问题

对于程序员来说，你可以使用任何框架，你也可以使用任何编程语言。程序员不就是要随时接受改变，随时学习新的东西吗？没人要你一辈子只能用 Flask 或是 Python。另一方面，即使别人都用 FastAPI 了，我用 Flask 又会怎么样？工具而已，只是按照需要做出适当或喜欢的选择。但是你起码要看一看文章再发表评论，而且也不用看到什么观点就相信什么观点（尤其是没有论据、结论先行的文章）。

同时建议 FastAPI 推介者保留一点体面。新事物的建立不一定要踩在已有事物的坟墓上。挑起对立只会导致 Python 社区的混乱。最后再引述我在上一篇文章的想法作结：

从长远看这些大都是一些临时问题，而且 FastAPI 作者已经开始全职开发开源项目，这些问题在未来应该都会慢慢得到改善。指出这些是希望更多的人可以客观看待 FastAPI，吹捧并不能让一个东西变得更好，参与开发、介绍用法和回答社区提问是比盲目吹捧更有意义的事情。我当然期待 FastAPI 能够越来越好，也期待看到有更多优秀的 Python 框架出现，但我不喜欢过度炒作、盲目的吹捧和错误的对比。

相关链接

• 本文在知乎上的讨论

演讲介绍

看着一个又一个 Flask 扩展失去维护，不再兼容新版本的 Python 和 Flask，我们能做些什么？在这个演讲里，我会介绍最近我和一些被遗弃的 Flask 扩展打交道的经历，包括如何更新一个古老的 Python 开源项目，以及正在实施中的一个拯救计划。如果你来自其他开源社区，那么这里介绍的经验或许也会帮到你。

录像和幻灯片

• 录像：YouTube | bilibili
• 幻灯片：https://greyli.com/slides/pyconchina2023
• 演讲中提到的 Flask 扩展健康监控项目：https://github.com/greyli/flask-extension-status

P.S. bilibili 认定金正恩的照片是违禁图片，留半秒都不行，最后只好贴了一只马在上面。浪费二十分钟。

照片

「代码厨房」最早是我创建的公众号的名字。同一时间注册了 daimachufang.com，想要在这个网站上放些什么已经不得而知。后来公众号一再改名，代码厨房已经不见。再一次想起来是在去年 10 月， 29 日心血来潮去参加中国开源年会的开源集市。作为现场唯一一个个人展位，我带去了两个项目。一个是方学园，另一个便是代码厨房俱乐部。

出发前一天为代码厨房俱乐部更新了 daimachufang.com（存档页面），也就是下面的样子：

俱乐部现场成立，现场报名。报名单上收集了十个人，最后筛选到五个。算上我自己，六个人在一年内完成了四次聚会。大家互相带来很多新想法和思考，也玩得很开心，但逐渐有点忘记最初想要做什么。于是，在 2023 年的 10 月 22 号，最后一次聚会，大家回到了报名的地方——微软 Reactor。我在那里重新介绍了代码厨房社区的构想。

代码厨房的核心构想是「一个让人快乐和放松的编程社区」，主要的板块是：

• Steak Overcooked：牛排煎糊了？把菜谱贴上来问问大家怎么办才好
• 活动：以爱好而不是商业目的出发的线上或线下活动
• 开源松：大家一起来做开源项目，推动一些项目的发展

不论你是当下、曾经还是未来的编程爱好者，都可以加入我们。代码厨房欢迎你！

APIFlask 2.0 版本的 codename 是 Gongqing（年初我从五角场搬到了共青森林公园旁边。没错，1.0 版本是 Wujiaochang）。

回到正题，这次最主要的一个变动（breaking change）是把所有 input 装饰器的参数改成了关键字参数。

@app.post('/pets')
@app.input(PetQuery, location='query')
@app.input(PetIn)  # equals to app.input(PetIn, location='json')
def create_pet(query_data, json_data):
    pass

关键字参数的名字默认是 {location}_data，通过 arg_name 参数可以自定义。这个改动让我删掉了很多 hack Flask 的代码。推动这个功能在上游 webargs 实现，所以不用加代码在自己这里。再加上一些改动已经在 Flask 实现了，又删掉一些。非常轻松。理想情况是，文档越来越多，代码越来越少。

如果你感兴趣的话，下面是 2.0 版本的详细内容：

• Changelog
• 2.0 migration guide

虽然这个项目还在很早期的阶段（突然心血来潮，然后刚买了域名的那个阶段），但我想这大概就是元宇宙，对吧？

我准备的奖品有几本书和一些 Flask 贴纸。趁 Flask 还没换上新 logo（嘘，内部机密），这次要把剩下的所有贴纸都送掉。

如果你有自己的开源项目，也可以来这里做分享，或是放到 HelloFlask 摊位来吸引别人参与。

感兴趣的话，用下面的链接报名活动吧（免费）：

• 活动报名：https://www.bagevent.com/event/8322865
• 详细活动介绍：https://mp.weixin.qq.com/s/S1UL9TkVd_BwH8ZoypoRpQ

下面是一个 HelloFlask x COSCon 2022 微信群聊，欢迎想来参会的朋友加入：

周六见！

这篇文章记录了我去年年末找工作的经历。最大的感想是，程序员找工作不一定需要刷题，很多公司是不考算法题的（除非目标就是那些字母组合公司）；其次是要有一些公开作品，比如开源项目，这样可以避免被使用某些单一维度评价；最后是不要提前对职位建立太多期待和想象。

2017 年我从扬州大学对面的大专毕业，在家待业五年后，终于没有钱再支撑下去。于是去年十一月开始正式找工作，十二月底拿到第一个 offer。今年年初来到上海，开始了第一份全职工作。

我一直把去某个公司上班看作是一个备选项。这几年经常幻想能写出一本畅销书，或是做出某个创业项目，然后就可以发财一直自由下去。但是基于钱出发的事情都不太有趣，基于兴趣出发做的事情又做得太多，所以钱越来越少，关于收入的焦虑感越来越强，最终只好投降。

个人背景

对于 IT 相关职位来说，我的优劣势大致如下：

劣势

• 专科学历
• 土木相关专业
• 待业五年
• 零工作经验
• 技术栈单一（Python/Flask）

优势

• 技术栈专一（Python/Flask）
• 参与开源项目的经验（从 2019 年开始做 Flask 的维护者）
• 一本书（《Flask Web 开发实战》）
• 一些技术演讲
• 创建和维护技术社区的经验（HelloFlask）
• 组织技术会议的经验（PyCon China 2019，FlaskCon 2020）
• 连续三年的微软 MVP 奖项（Python 方向）

从 2016 年实习即回家开始算起的话，我的简历上大概有五年零三个月那么大的空白。不过虽然没工作，这五年也尝试了各种有意思的事情，同时为了获得收入打了一些零工——做了七八个外包项目。

这些外包项目不算优势也不算劣势，但是可以用来填充简历——简历上放了两个开源项目（Flask 和 APIFlask）和两个外包项目。而有些劣势也不完全算劣势，比如非科班自学编程，有些 HR/经理会认为不专业，有些则认为这佐证了学习能力和执行力。

求职方向

我对目标职位的三个需求是：

1. 不加班
2. 面试不考算法题
3. 现场（on-site）工作

「不加班」是基本要求，我需要一份正常工时的工作，一来是为身心健康着想，二来是因为我需要有业余时间来写书和做开源项目。

「面试不考算法题」是因为不想浪费时间去刷无聊的算法题。算法题对我来说没有任何乐趣，相比之下，我更喜欢开发 Web 程序和设计 API。

想要一个「现场（on-site）工作」是因为很想去体验办公室生活，顺便体验在不同的城市生活。在家呆了五年后，我也有些厌倦在家工作。太容易过度娱乐和过度工作，模糊生活工作的边界。我想要有一个办公空间来把工作和生活在时间和空间上分隔起来。

国内公司普遍加班，互联网公司普遍考算法题，因此能够满足这三点的只有「非互联网 + 外企」职位。结合我擅长且感兴趣的技术栈（Python Web）和想要去的城市（上海），最终的求职方向是「上海 | 外企 | Python 后端工程师」。

职位搜寻

我在下面这两个地方搜集了 14 个和 Python Web（尤其是 Flask）相关且位于上海的外企职位：

• LinkedIn 搜索关键词「Flask」
• 一个偶然发现的职位采集站点

Python 和 Flask 相关的工作还是挺多的，我只收集了上海 on-site 的外企职位，如果扩大范围还可以找到更多。后来我把一些没有来得及投递或已经收到拒信的 Flask 相关职位放到了 GitHub 上。

这两个网站的职位都提供公司网站的招聘链接。我倾向于在公司网站投递简历。虽然没有证据，但我认为这会比在招聘网站上投递更容易被看到。如果招聘网站上直接展示你的资料，比如学历和工作经验，这会降低 HR 打开简历的概率。不过招聘网站可以用来参考薪资范围。

职位投递和面试

我的职位投递策略是只投递自己想去的职位，按照优先级投递，能够拿到一个 offer 就可以。为了把最多的时间投入在优先级更高的职位，我按照意向程度和技术栈匹配程度把这 14 个职位分成了三批。

第一批两个职位在 11 月 20 号左右投递：

• 育碧：二面挂
• 博世：口头 offer

第二批四个职位在 12 月 7 号投递：

• 戴尔 EMC：offer
• Autodesk：二面挂
• 万事达：电面通过，后续没有继续面
• 特斯拉：简历无回复

我统计了每一个职位的时间花销，包括准备面试和面试本身花费的时间。因为不用花时间刷算法题，所以这里的准备主要是：

• 看出现在职位描述上或是简历技能列表里的相关技术知识，也就是俗称的八股文
• 练习英语口语，主要是在口语网站上和一些外国人模拟面试对话
• 了解对应职位和公司，收集相关面经
• 准备常见非技术问题的回答
• 准备项目经历介绍
• 针对每个职位更新简历

育碧

时间花销：22h 21m

• 11/19 上午官网投递简历
• 11/19 下午收到约电面时间的邮件
• 11/25 电面二十分钟，主要聊经历、技术栈和面试安排
• 11/25 下午收到跳过笔试的邮件
• 11/26 收到技术面安排邮件
• 11/30 技术面，一个半小时
• 12/6 拒信

育碧是一家游戏公司，这可能不应该作为申请职位的主要考量因素，但这的确是最吸引我的一点。哪个喜欢玩游戏的程序员不想去一个游戏公司上班呢？而且入职后还可以免费玩所有的育碧游戏。我把它放到了职位申请列表的最上面。

电面时 HR 告诉我职位对应团队的同事看了我的 GitHub 资料，觉得很惊艳。后续还帮我跳过了笔试环节。不过技术面发挥得一般，有一些算法和 Python 元编程相关的问题没有回答上来。两位面试官在会议室里，声音不是很清晰。

这是我自大学毕业以来的第一次技术面试。在之前的几年里，我有过五六次找工作的经历，大多是朋友推荐，最后因为各种原因不了了之。唯一进入面试的是一个德国的远程工作，因为我的英语水平一般，加上对方有一些口音，所以还没来得及探讨技术话题就匆匆结束了。

博世

时间花销：24h 13m

• 11/22 中午官网投递简历
• 11/22 下午接到经理电话，算是电面，聊了经历、技术栈、目标职位的职责，最后约了技术面时间
• 11/24 技术面
• 11/25 技术面反馈，布置小作业
• 12/1 基于小作业的跟进面试
• 12/2 谈薪资
• 12/3 口头 offer，协商薪资
• 中间来回几轮薪资谈判
• 12/25 HR 回复职位因为疫情推迟招聘到明年二月

博世的职位描述和我的技术栈非常匹配，而且要求看起来很简单。简历处理效率很高，上午投递申请，下午就接到电话。

整个面试过程很顺利。技术面和育碧类似，主要是问 Python/数据库/HTTP/Linux 相关的一些东西。技术面后布置了一个小作业，是实现一个包含特定功能的 Teams bot，给了一周时间。提交作业后的第二天 HR 来谈薪资，再隔一天给了口头 offer。不过 offer 薪资和意向差得很远，我就请 HR 再帮忙协商协商，后来 HR 不知道为什么理解成我拒了 offer。经过几次艰难的谈判后我开始妥协，然而一个月后 HR 回复因为疫情暂停招聘了……

Autodesk

时间花销：13h 25m

• 12/7 官网投递简历
• 12/9 下午接到 HR 电话，聊了经历、期望薪资、简单英语对话考察，电话刚挂没多久就收到拒信
• 12/10 接到另一位 HR 电话，直接约了一面时间
• 12/13 一面
• 12/14 HR 约二面
• 12/15 二面
• 12/23 拒信

这个职位一开始发生了一些乌龙，后来才明白是因为简历被投递的部门拒了，然后又被另一个部门的经理打捞回来。一面就是经理面，主要聊了我的经历、公司业务和技术栈等等。这位经理很赏识我，整场面试一半时间都在挥动橄榄枝，这给我屡屡失败的面试重新建立了很大的信心。

可惜最终止步于二面，因为有一位面试官对我的稳定性表示担心。二面是技术面，除了一个关于排序算法的问题卡顿了好久才勉强回答，大体表现还不错。

戴尔 EMC

时间花销：10h 2m

• 12/7 官网投递简历
• 12/16 接到 HR 电话，介绍面试安排
• 12/17 连续两场技术面，各一小时
• 12/22 早上 HR 电话安排终面
• 12/22 中午终面
• 12/22 下午 HR 电话谈薪资
• 12/29 确认薪资和 offer

接到 HR 电话就直接介绍了面试安排，没有聊其他东西。技术面第一场问了很多涉及各个方面的技术问题，还有一段英文对话考察；第二场出了一道简单的算法题，二分查找，不过基于矩阵的变式没做出来。职位描述里除了 Python 和 Flask 还列出了很多我不太熟悉的东西，后来发现这些都没有问。终面是经理面，主要聊一些技术方向、职业规划之类的话题。终面结束后下午就接到 HR 电话谈薪资，29 号确认了 offer。

收到 offer 后非常开心，毕竟是人生第一个 offer，第一时间就开了薯片庆祝：

最终拿到 offer 的职位反而是这几个面试里花费时间最少的一个（大部分技术问题相关的准备都已经在前面的面试做得差不多了），也是唯一考了算法题的一个。

万事达

• 12/7 官网投递简历
• 12/28 HR 电面，聊经历、期望薪资、简单英语对话考察
• 1/4 因为已经确认了戴尔 offer，所以取消了后续面试

因为安排太晚，所以没有继续面。后续 HR 说经理对我的简历很感兴趣，问我要不要再聊聊，但我实在不想再折腾面试了。

除了上面这六个主动申请的职位，这段时间还有三个被推荐和邀请的职位，完整参与面试的是下面两个。

Dropbase

时间花销：6h 6m

• 11/20 收到面试邀请邮件
• 11/27 一面
• 12/1 拒信

一个湾区创业公司，技术栈主要是 Python 和 Flask，远程工作。通过 APIFlask 项目找到我。这个职位看起来很不错，不过我当时更偏向找一个 on-site 工作，所以没有花太多时间准备。面试是和两个公司创始人聊天，没有考算法题，一周后收到了拒信。这个职位现在仍在开放，感兴趣的朋友可以试试看。

AWS

时间花销：29h 40m

• 11/16 内推提交简历
• 11/17 HR 电面，聊经历、期望薪资
• 11/23 一面
• 11/25 拒信

在 AWS 工作的朋友推荐，职位是解决方案架构师，这是我第一次了解到这个职位。30 个小时时间花销大部分是用来准备 Amazon Leadership 和 BQ 问题。一面挂，38 分钟。

备选职位方向：开发者布道师

在十一月底搜集和投递 Python 后端方向的职位之前，我先在开发者布道师（Developer Advocate）方向做了一些零星尝试。这个方向可以申请的职位并不多，而且大多和 Python 没有关系。最终只面了两个职位，均止步于一面。

这个职位的日常工作基本都是我擅长和喜欢做的事情：写作、演讲、分享、教学。如果目标职位的产品和我的技术背景接近的话，我就可以继续在喜欢的主题（Python）产出内容。

一开始是朋友推荐的职位：

• Nebula Graph：一面挂

面试后我继续申请了几个职位。下面这几个职位除了最后一个都是通过 Google 搜索关键词「Developer Advocate China」找到：

• TigerGraph：简历无回复
• JetBrains：一面挂
• AWS：简历无回复
• Jina AI：一面后转到后端工程师方向，所以没有继续面

微软

时间花销：22h 30m

第一次了解到开发者布道师这个职位是在四月份，当时微软第一次在国内招聘开发者布道师，朋友推荐我去试试。

我一开始认为自己是非常合适的人选，后来发现这个职位更希望候选人有 Azure、AI 相关的背景（职位名称是 Cloud Advocate 而不是 Developer Advocate）。折腾了很久，最后并没有拿到面试机会。后来微软有一个面向 GitHub & VS Code & Open Source 的开发者布道师职位，看起来更适合我，不过没有在国内开放。

因为我在捕蛇者说的一期播客聊到了这件事，所以有朋友推荐了 Nebula Graph 的职位。

Nebula Graph

时间花销：35h 29m

• 10/12 一面

这是一个面向开源数据库项目 Nebula Graph 的「社区布道师」职位，对我来说是完全陌生的领域，所以有很多准备工作可以做。初次接触后我就迅速下单了两本图数据库相关的书（不过一本看了开头，一本还没拆封）。花了一些时间快速熟悉 Nebula Graph，在这个过程里发现了很多网站、文档、项目上的问题，所以就把这些问题整理了下来（见这篇《Nebula 网站和项目捉虫》）。然后陆续给他们的几个项目提交了一些 PR（代码贡献）。

一面后，我继续提交了一些 PR，作为「如果入职的话会帮忙做哪些改进」的提前展示。不过后面就再也没有收到关于下一轮面试的回复。直到一个月后的某天，HR 提起我上个月的 PR，按照社区规则要给我寄纪念品。微信对话的最后，我问 HR 对上个月的面试有没有什么反馈和建议，但是对方似乎没有看到这条消息。为了打捞学习图数据库沉没的成本，之后我继续投递了 TigerGraph 的布道师职位，结果一沉再沉。

不过没关系，我很快发现了更喜欢的开发者布道师职位——PyCharm Developer Advocate。

JetBrains

时间花销：23h 49m

• 10/14 官网投递简历
• 12/3 收到 HR 邮件
• 12/6 一面
• 12/22 收到拒信

JetBrains 的 PyCharm Developer Advocate 是这一批开发者布道师方向里最喜欢的职位，因为这和我目前擅长的技术领域一致，我可以继续做和 Flask/Python 相关的事情，不用盖新房子。

十月用 Google 搜索到这个职位，顺手就投递了。中间几次找在 JetBrains 工作的朋友打听，但是一直都没消息。十二月初终于收到 HR 的邮件，约了三天后面试。

收到邮件后，我开始幻想入职这份工作要做些什么，兴奋到很晚才睡着。其实早在申请职位的时候我就已经做了一番规划并注册了 hellopycharm.com。收到回复的第二天，我写了一封表白信放在 hellopycharm.com 上（然后在回复邮件时不经意地提起这个网址）：

当时 JetBrains 刚刚在上海成立了分公司，取名捷并思，但我更喜欢「喷气脑」这个名字，所以之后还注册了 penqinao.com，放了一个 logo 在上面：

面试的前几天刚结束另一场英语面试，所以语言问题不大。而且我还在某个英语口语网站上找到同样来自捷克的另一位 Monika 来模拟面试（JetBrains 的 HR 也叫 Monika）。

月底收到拒信说她们希望找到一位有数据科学背景的候选人，不过我在面试时就问过这个问题，她们回答说没关系……

不过还是没关系，对我安慰作用最好的一种说法是，开发者布道师的工作对现在的我来说不是最佳选择。

我在过去几年做演讲和写文章都是跟随自己的兴趣和关注点，如果变成为某个公司的产品/项目——尤其是一个新的领域——做大量的输出，一定没法再像之前那样轻松愉快。另一方面，这类职位的公司也许更想找一位有很多年工作经验、技术栈丰富的人，而我正在找第一份工作，我还只会 Python。

PyCharm 这个职位收到拒信后，我就决定放弃这个职位方向。先做一个后端开发职位会是更好的选择，这样我就可以继续按照自己的喜好演讲和写作，没有任何拘束，而且也有时间踏实学东西，多做积累。

总结

在网络上经常看到有人每天都刷算法题（LeetCode），在无形中制造了一种不刷题找不到工作的紧张气氛。这次找工作才发现不一定需要刷题。有一些公司是不考算法题的，比如大部分非互联网行业的外企和某些创业公司。还有一个 GitHub 仓库记录了所有不需要白板测试（算法题）的公司名单，对应的网站可以用来检索所有不考算法题的开放职位。如果实际工作只是 CRUD，那么实现一个小项目，或是抽象一个公司产品的小功能出来远比考算法题有意义得多。

即使不用刷题，找工作也是一件很累的事情。要承受别人的否定，会认识到自己的局限和不足，然后还有无穷无尽的等待，等待充满随机性的结果。

更糟糕的是，我对每一个投递了申请的公司和职位都建立了太多的期待。除了面经，我还会收集每一个公司的各种信息：公司位置、公司评价、工作环境、周边环境，甚至附近有哪些合适的房子可以租。对于拿到面试机会的两个布道师职位，我都规划了入职后会做什么，具体到可以做的演讲主题、示例程序和教程，并且还提前注册了一些域名。当这些职位收到拒信后，这些期待和规划就全部落空。

经常会觉得自己是某个职位的最佳人选，然后就煞有其事地在晚饭时告诉家人接下来我即将会去哪个城市哪个公司上班……

12 月 22 号到 12 月 28 号是最黑暗的一周。22 号收到 JetBrains 拒信——最喜欢的布道师职位；23 号收到 Autodesk 拒信——最受赏识的职位；25 号博世回复暂停招聘——离 offer 最近的职位。如果没有拿到戴尔的 offer，那就要继续投递第三批职位，经历更多的面试和拒信，想想就后怕。

最后要感谢很多在这段时间提供帮助的朋友们。感谢辛庆老师、思为、清蒸、Aleck、伊洪、Tzu-ping Chung、Joshua Bronson、大妈、琚致远还有其他在 Twitter 和微信上给我推荐工作机会的朋友们；感谢开发者布道师前辈们——Anthony Shaw、思为、朱兴亮和范圣佑提供了很多面试建议；感谢职场前辈张晋涛老师在入职前给我科普了很多职场经验。

同时感谢每一个给我面试机会的 HR 和经理（尤其是戴尔 EMC 的 Fiona 和 Kui），不管我是千里马还是百里马，你们都是我的伯乐。

最近公司又开放了几个新的 Python/Go 职位空缺，如果感兴趣的话，一起来做同事吧。

职位要求：

• 计算机相关学士学位或 1~2 年软件开发经验（另外还有对应 3~5 年以及 10 年以上经验的职位）
• 熟悉 Python/Go/Java（任一，最好是 Python/Go 方向）
• 熟悉 Linux 和 Git 的使用
• 熟悉 Flask 或其他 Web 框架
• 有 REST API 开发或微服务相关经验
• 了解容器和容器编排系统（Docker、Kubernetes、Rancher 等）

加分项：

• 了解 Angular/React/Vuejs（任一）
• 了解 MySQL、PostgreSQL 或其他 DBMS
• 了解或使用过 Jenkins
• 参与过开源项目
• 有网络、安全、虚拟化、云平台相关经验

工作地点在上海/成都/台北。工作时间正常，不加班，不打卡，周末双休（965）。混合办公，每周可以最多五天居家办公（不限定时间，在正常工作和沟通的前提下，可以自己安排）。

联系方式：

• Email：grey.li@dell.com
• 微信：greyli_work

发布上个版本已经是 2019 年的事情了，这次针对 Flask 最新的 2.1.3 版本做了改写，同时不再兼容 Python 2.7 版本。优化了前面几章的一些内容，后面的章节需要改动的地方不多，就没有认真去更新。另外还顺便用 MkDocs 和 Netlify 把教程重新部署到了 tutorial.helloflask.com 上，后续会废弃掉 GitBook。

过去三年里，这本电子书大概给我带来了五百块的收入（主页上有一个自愿点击的「付费支持￥10」的按钮）。虽然不多，但是时不时收到到账提醒和鼓励的话还是很开心的。感谢每一位付款的读者！

当然，给我带来更大成就感的是看到读者分享他/她通过阅读这个教程写的程序，这是一种给别人带来成就感的成就感——元成就感。

APIFlask 是一个基于 Flask 和 marshmallow 实现的 API 框架（详细介绍见这篇文章）。经过一年的迭代，终于在这个月初为它发布了 1.0 版本（撒花~）。

• GitHub：https://github.com/apiflask/apiflask
• 文档：https://apiflask.com/docs

1.0 版本主要带来了三个新功能：

• 支持处理文件上传，新增 File 字段
• 支持使用外部的认证库
• 添加了几个新的请求解析位置：json_or_form、form_and_files 以及 path

一个 API 变动（breaking change）：

• input、output、doc、auth_required 这四个装饰器移动到了程序实例和蓝本实例上（比如 app.input() / bp.input()）。

还有一些代码上的修正和优化，具体可以在变更日志里看到。欢迎更新试用和提交反馈：

$ pip install -U apiflask

在代码之外，也有一些变动和改进：

• 完成了所有基本文档的写作（有些内容仍需优化）
• 启动了中文文档翻译项目（欢迎参与）
• 主仓库转移到了单独的 GitHub 组织
• 添加了更多的示例程序

如果你正在用它开发你的个人项目或是公司项目，欢迎在这里留言告诉我们（我）！