Vokabry - Learn Vocabulary with AI
Learn vocabulary with AI assistance
- 参与金融平台建设，负责具体模块的设计、开发与维护。
- 协助产品经理分析业务需求，进行技术方案的设计与落地。
- 参与解决高并发、大数据量等场景下的技术问题。
- 在指导下完成核心模块的开发任务，并具备一定的代码质量和规范意识。
- 配合团队完成项目研发，具备良好的协作与沟通能力。
岗位要求
- 扎实的JAVA基础，熟悉常用框架（如Spring、MyBatis等）并了解其基本使用与配置。
- 1-5年JAVA开发经验，了解分布式系统的基本概念，有高并发系统开发经验者优先。
- 具备一定的业务理解能力，能参与需求讨论并进行技术方案初步设计。
- 具备良好的主动性、责任心和沟通能力，能清晰理解任务并落实执行。
- 有认证、支付相关业务经验者优先。
简历投递方式
请将简历发送到 [email protected]，标题注明“高级后端工程师 - 姓名”。
更多信息
- base: 上海·杨浦
- 内推链接: 后端-上海-高级(J13296)
1 个帖子 - 1 位参与者
]]>欢迎大家也分享自己的年总结和新年计划！
很惭愧，我的新年目标是去年没完成的那几个……
- 恢复健康（正常人 80% 水平）
- 多用英语（主要是写和说）
- 日语入门（记住五十音图？）
- 学会自由泳
- 学会开车
不过今年还多了两个年度挑战 
- 一年不买新游戏挑战
- 一年不买新书挑战
1 个帖子 - 1 位参与者
]]>http://154.221.16.23:3000/
2 个帖子 - 2 位参与者
]]>
vokabry.app
- 无需配置 API Key
- 划词翻译
- 文本替换
- 单词学习
- 单词测验
- 数据在本地
现支持 MacOS + Windows，完全免费，欢迎大家下载试用、反馈
3 个帖子 - 3 位参与者
]]>社区展位
今年代码厨房准备了更多的贴纸，除了社区贴纸，还有本次几个开源松项目的 logo 贴纸，以及去年设计但忘记送的 Foobar 变量贴纸。
在展位上设计了两个活动，分别是「流浪记事本计划」和「开发者精神状态调查」。社区的本质是连接志同道合的人。在开源协作之外，这两个活动分别探索了用圆形贴纸和记事本作为连接媒介的可能。
社区活动之「流浪记事本计划」
流浪记事本的想法始于想在社区展位做一个留言本，后来想到不如让记事本自己去流浪，找到想写东西的人。
上午活动开始时，@frostming 作为第一棒带着本出发了。虽然最后接过笔记本的人没有按照提示归还，但我还是在主会场的最后一排找到了它：
大家在上面写了各种留言、涂鸦和笔记：
关于流浪记事本的整个故事和收集到的大部分留言可以在这篇文章看到。
社区活动之「2025 开发者精神状态调查」
我一直很好奇大家对待生活、工作和编程是什么样的态度，所以这个活动算是从满足自己的好奇心出发的。因为 A3 尺寸太小，调查问卷只设置了五个问题，参与者通过用贴纸贴到对应区域来回答问题。
最终吸引到大概 150 人参与投票：
虽然考虑到会有样本偏差（只采样线下来参加活动的人），而且还有一些干扰数据：
但还是没想到大家的精神状态那么健康：
开源松 Sprint 7
开源松 Sprint 7 在分会场 E 举办（上海对外经贸大学贸源楼 106 教室），是一间很温馨（小）的教室（以至于后面很多人没能挤进来）。
这次开源松设置了 5 个项目：
- WikiSurfing：WikiSurfing is an endless wiki that creates new articles using AI.
- Running Page：Make your own running home page.
- Fine Weather：An album application.
- Stata-MCP：Let LLM help you achieve your regression with Stata. Evolve from reg monkey to causal thinker.
- APIFlask：A lightweight Python web API framework.
下面是每个项目的路演视频：
- WikiSurfing：无限的虚拟维基百科 - 盐粒 (Yanli.one) @yanli - VESoft (NebulaGraph)
- Running Page：打造你自己的个人跑步主页 - 伊洪 - Xenera
- Fine Weather：打造你自己的个人相册 - 李辉 @greyli - 代码厨房管理员
- Stata-MCP：用 AI 落地数据类学术研究？真的！ - Sepine @SepineTam - 上海大学本科生，比翼视界CEO
- APIFlask：我与 APIFlask 的故事 - 黎文翀 @Farmer-Chillax - 小鹏汽车研发工程师，代码厨房 Member
幻灯片：slides/soos7 at main · codekitchen-community/slides · GitHub
代码厨房 x PyCon 音乐会
按照惯例，这次开源松依然以代码厨房乐队演出结尾。演出由周煦林 @voidZXL 和卢书洋 @ZinkLu 带来：
演出录像：代码厨房 x PyCon 音乐会 @ PyCon China 2025
下次活动见
感谢所有来参与活动的朋友，期待下次再见！
加入厨委会
想不想加入我们一起策划和举办下一场好玩的活动？欢迎填写下面的申请表单加入我们的志愿者团队——「厨房组委会」：
厨房动态
关注我们的社交网络获取动态更新：
- 公众号：codekitchen
- Twitter：codekitchen_
- 小红书：codekitchen
- bilibili：代码厨房
活动开销统计
本次开销由 @greyli 赞助：
- 冰箱贴 20 个 ¥70
- 贴纸 100 张 ¥160
- 易拉宝 ¥106
- 记事本 + 胶带 + 笔夹 ¥20
- 调查问卷支架 + 圆形贴纸 ¥40
另外感谢 @Farmer-Chillax 赞助的小鹏汽车模型玩具以及 PyCon China 赞助的鼠标垫。
致谢
本次开源松所有流程和物料设计都由 @greyli 完成。感谢 PyCon 组委会和上海对外经贸大学提供会务和场地支持，感谢志愿者们提供现场支持：
展位支持：高佳 @gaoshizhendegao、吴小朋、@Farmer-Chillax、@gaojingru
摄影摄像：雾雨魔理莎、Await
1 个帖子 - 1 位参与者
]]>flask 在获取上传的文件参数时，有两种方式：
request.filesrequest.files.getlist
如果使用 request.files ：
- 单文件上传时，通过参数名获取到的是单文件
- 多文件上传时，通过参数名只能随机获取到多个文件中的一个文件
如果使用 request.files.getlist ：
- 单文件上传时，通过参数名获取到的是一个仅包含被上传的单文件的列表
- 多文件上传时，通过参数名获取到的是一个包含所有被上传文件的乱序列表
也就是说，获取到的参数的类型仅与获取参数的方式相关，而和这个参数在被上传时，是单文件上传还是多文件上传无关。故无法判断客户端的初始意图是上传单文件还是文件列表。在将参数转换为 Pydantic 模型时，也无法将文件参数类型进行精确匹配，因为无法知悉其到底是文件类型还是文件列表类型（如上所述，这仅取决于获取参数的方式，无法判断客户端的初始意图是什么）。
也许还有其他什么我尚不知晓的获取文件参数的方式？或者大家有什么其他的想法或思路可以处理这个问题？
欢迎大家留言讨论，不胜感激。
以下是最小演示示例：
app.py
from flask import Flask, request
from werkzeug.datastructures import FileStorage
app = Flask(__name__)
@app.route('/upload', methods=['POST'])
def upload_file():
# 单文件
assert isinstance(request.files['single_file'], FileStorage)
assert request.files['single_file'].filename == 'test.txt'
# 使用 request.files.getlist 即使是单文件也会返回一个 list
assert isinstance(request.files.getlist('single_file'), list)
assert len(request.files.getlist('single_file')) == 1
# list 中只有一个元素，就是这个单文件
assert request.files.getlist('single_file')[0].filename == 'test.txt'
# 多文件
assert isinstance(request.files.getlist('multi_files'), list)
assert len(request.files.getlist('multi_files')) == 3
# 使用 request.files 会获取到列表的首个文件
assert isinstance(request.files['multi_files'], FileStorage)
# 以下这个断言会概率性失败，因为 list 中文件的顺序和上传顺序并不一定一致
# assert request.files.getlist('multi_files')[0].filename == 'test1.txt'
# 但通过 request.files 获取的一定是 list 的首个文件
assert request.files['multi_files'].filename == request.files.getlist('multi_files')[0].filename
return {"message": "Passed"}
requests客户端：
import requests
rv = requests.post(
"http://localhost:5000/upload",
files={
("single_file", ("test.txt", open("test.txt", "rb"), "text/plain")),
("multi_files", ("test1.txt", open("test1.txt", "rb"), "text/plain")),
("multi_files", ("test2.txt", open("test2.txt", "rb"), "text/plain")),
("multi_files", ("test3.txt", open("test3.txt", "rb"), "text/plain")),
},
)
版本信息：
flask: 3.1.2
requests: 2.32.5
2 个帖子 - 1 位参与者
]]>
。内容很丰富，激情阅读中！
2 个帖子 - 2 位参与者
]]>
程序员不止写代码。
有人建社区、搞乐队、组织开源松，也有人默默在做点理想的事。
「#代码厨房播客」第一期上线！
主持人 苏雄 对话 李辉（Grey） ——
Flask 团队成员、《Flask Web 开发实战》作者、「代码厨房」社区发起人。
他们聊了：
-
非盈利技术社区如何运作？
-
为什么程序员也需要“共情力”？
-
技术书出版的坑与经验分享
-
从“理想主义”到“流程自动化”的平衡
一句话概括：
这是一期程序员之间关于理想、执行与温度 的长谈。
在各大平台搜索「代码厨房播客」收听吧！
小宇宙收听：Ep 01. 与李辉聊聊代码厨房播客和社区的构想 - 代码厨房 | 小宇宙 - 听播客，上小宇宙
3 个帖子 - 3 位参与者
]]>感谢 @uncle-lv @Farmer-Chillax @tyang.sh3 参与贡献！
1 个帖子 - 1 位参与者
]]>Improve the startup performance
已打开 08:18AM - 13 Nov 25 UTC
frostming
⭐ enhancement
❓ help wanted
💝 good first issue
### Feature Description Now PDM startup is still very slow, most of the time is…
有兴趣可以来贡献
1 个帖子 - 1 位参与者
]]>网站地址：
实机演示：
简单来说，其实就是一个「导航页」，但和一般的搜索导航站相比，「易查」不仅支持自定义，而且还多了一步「分析搜索结果」——判断对应网站是否存在有意义的搜索结果，并将结果显示在页面上。
另外还（会）实现一些功能：
- 分析整个句子，（基于收集的数据）预测用户可能想查的单词，尤其是光标附近的单词/词组/句型
- 日语会使用 Mikann 作为分词器
- 英语和其他语言会使用 spaCy 作为分词器
- 云同步
- 查词记录支持导出到 Anki
- 通过爬虫和 sitemaps 的缓存，提高「分析搜索结果」的速度
由于还处在早期开发阶段，所以现在每次查询会把20多个网站在服务器挨个打开一遍，看那些网站返回的结果有没有指定的关键字，所以速度会非常慢，这个网页暂时当做最后的备用手段吧2333。
之后我会结合用户反馈，把一些较为常用的搜索词的结果整理到数据库，访问起来就会快得多了，但具体哪些网站和哪些词，我想看看大家的建议。
另外，公开一份我自己维护的在线辞典网站，学日语和英语的话，可以看看：
4 个帖子 - 2 位参与者
]]>谢谢各位大佬！
1 个帖子 - 1 位参与者
]]>Git的每一条commit记录都应该对应当前仓库.git/objects目录下的一个Git对象(本质上是一个文件)。
例如：4e1951ba977e84d72c3c7f754b61b1c911f24aff这个SHA-1 hash对应的Git对象应该是objects目录的子目录4e下的名为1951ba977e84d72c3c7f754b61b1c911f24aff的文件。
但当这条记录是GitHub仓库的初始化commit时，却找不到对应的Git对象（甚至没有4e这个目录），同时这条提交的一切信息又可以通过git cat-file命令正常打印。详见下图。
是这条commit单独存储在其他地方了吗？
或者是有什么其他我不知道的细节？
本地初始化的Git仓库无此问题。
有关Git对象的更多信息可以参考此博客。
2 个帖子 - 1 位参与者
]]>- WikiSurfing：无限的虚拟维基百科 - 盐粒 (Yanli.one) @yanli - VESoft (NebulaGraph)
- Running Page：打造你自己的个人跑步主页 - 伊洪 - Xenera
- Fine Weather：打造你自己的个人相册 - 李辉 @greyli - 代码厨房管理员
- Stata-MCP：用 AI 落地数据类学术研究？真的！ - Sepine @SepineTam - 上海大学本科生，比翼视界CEO
- APIFlask：我与 APIFlask 的故事 - 黎文翀 @Farmer-Chillax - 小鹏汽车研发工程师，代码厨房 Member
代码厨房 x PyCon 音乐会：
幻灯片（上传中）：
1 个帖子 - 1 位参与者
]]>1 个帖子 - 1 位参与者
]]>代码厨房管理员 @greyli 有一些记事本，它们在书架上分别落了几个月到几年时间的灰尘。大家都很消沉，感到生活无望。“能做个草稿本也是好的”，有些本子这样抱怨；“还不如一片叶子光荣”，有些精神状态堪忧。然而管理员只爱他的键盘，早已忘记了它们。某一只记事本受够了这样的生活，看到书桌上管理员这几天成天鼓捣的 PyCon China 2025 活动，决定出去闯一闯。
它犹豫踌躇了很久，最终还是鼓起勇气和管理员表达了自己的想法。没想到的是，管理员非常支持，还说了很多“年轻人多出去闯一闯是好的”、“流浪才是健康的生命状态”、“重新建立附近的概念”、“让社区起到联结彼此的作用”之类奇怪的话。说完了就闷头干起活来，没一会儿就为它做了一张海报：
本的流浪
故事的主人公就这样定下了它的流浪计划。它的名字叫本，英文名自然就是 Ben。大会开始前的几天，它总是精神满满，和其他记事本说话时也充满自信（趾高气昂），每句话都是以“本本”开始。你以为在说可爱的叠字？其实它只是在模仿人类的语气而已——“本本（本人）明天就要出发去 PyCon China 了！你们都没去过吧？”。
因为怕它被坏人劫持，管理员还帮它把海报打印出来，贴到电梯一开门就能看到的地方：
也在它的身上放了防丢说明：
这是一场漫长的流浪，个中曲折暂且不表。下午六点钟，眼看约定的回家时间要到了，它却绝望地发现自己被遗弃在了会场的最后一排（镜头从本的视角拉远再拉远：偌大的会场，一排排冷漠的座椅，本在后排已经渺小到看不见）。
好在管理员寻遍了每一个会场，最后顺利发现了它。幸好找到了它，这也让本的这次流浪能够有一些成果可以展示。
本的记忆
在这一天的流浪里，本记住了很多东西。让我们看看大家都写了什么吧！
管理员的出发寄语：
主会场看起来确实很冷：
今年也确实没有差旅报销：
呼唤远方某位著名 Python 开发者：
捕捉 Saka ：
表白 yihong：
表达语言和框架的偏好：
对管理员产生了好奇：
进行一些程序员经典简笔画练习：
也有人在认真记笔记：
或是写一些难以理解的话：
还有很多对 PyCon China 的祝福和肯定：
本的遗憾
它说这次活动还有一点遗憾，原话是这样说的：“本本本来希望可以多走一些地方，没成想被困在了主会场一整天。本本下午本来是想去另一栋楼 106 教室的代码厨房开源松会场的，去看看那里的朋友们在做些什么，写了哪些代码，唱了什么歌……”
“那么下次流浪是什么时候呢？”发现自己要被放回书架的时候，它急忙问了这个问题。
7 个帖子 - 4 位参与者
]]>- make mapbox token to secret · Issue #1003 · yihong0618/running_page · GitHub
- theme color on map not change when total map · Issue #1004 · yihong0618/running_page · GitHub
- make summary page faster · Issue #1005 · yihong0618/running_page · GitHub
1 个帖子 - 1 位参与者
]]>repo: GitHub - WondersTown/WikiSurfing: WikiSurfing is an endless wiki that creates new articles using AI.
issue:
- [chore] Enhance Devlopment Docs [chore] Enhance Devlopment Docs · Issue #1 · WondersTown/WikiSurfing · GitHub
- [web] New UI design and refactor code architecture [web] New UI design and refactor code architecture · Issue #5 · WondersTown/WikiSurfing · GitHub
- [core] Avoid “World Convergence” [core] Avoid "World Convergence" · Issue #4 · WondersTown/WikiSurfing · GitHub
and more on GitHub · Where software is built
1 个帖子 - 1 位参与者
]]>
1 个帖子 - 1 位参与者
]]>Repo: APIFlask (github)
- 修复现在的 unit test，使其能跑起来 · APIFlask (github)
- Add return type information from APIFlask route method helpers · issue #666 · APIFlask (github)
- Add OpenTelemetry usage docs · #672 · APIFlask (github)
19 个帖子 - 4 位参与者
]]>Repo：GitHub - SepineTam/stata-mcp: Let LLMs help you achieve your regression with Stata: AI-Powered Stata Code Generation & Regression Analysis.
- StataFinder class update：目前StataFinder组件中windows和Linux的支持存在问题—如果Stata未在默认路径安装会出错。
- get_data_info function fix：对于get_data_info函数，目前传入的数据仅允许dta和标准数据xlsx格式，同时存在很多未知错误，性能也待优化。
- SandBox.Jupyter new！目前的Stata-MCP的运行是以dofile为单位，但很多时候会希望用session形式进行运行。
1 个帖子 - 1 位参与者
]]>Repo： codekitchen-community/fine-weather: An album application. (github.com)
- Create contributing guide · Issue #32 · codekitchen-community/fine-weather (github.com)
- 优化图片上传表单 · Issue #23 · codekitchen-community/fine-weather (github.com)
- 支持设置不同颜色主题 · Issue #22 · codekitchen-community/fine-weather (github.com)
6 个帖子 - 3 位参与者
]]>参与方式很简单，用圆型贴纸贴到每个问题的答案区即可，示例见图2。
2 个帖子 - 1 位参与者
]]>1 个帖子 - 1 位参与者
]]>细节和完成进度会持续更新中。如果你对某项任务感兴趣，欢迎认领和参与讨论。
目前需要帮助的部分：
- 媒体宣传（比如小红书账号运营，或者干脆放弃这个平台？）
- 设计（比如方向指引海报，日程海报等）
- 需要乐手，大量招募乐手！
P.S. 下周开始，我会逐一确认已经报名的厨委会申请，并添加编辑权限。
1 个帖子 - 1 位参与者
]]>最近开始为 PyCon China 2025 的代码厨房特别活动做准备了，同时也在准备建立厨委会，先来总结一下去年的花销。
花销统计
去年的 PyCon China 2024 专场开源松活动 花销如下：
- 易拉宝 119
- 冰箱贴 99
- 贴纸 130
- 小礼品 173
- 道具 16
- 去活动现场打车 64（去的时候带的东西太多，所以也算作活动开销）
总计 602。
另外 PyCon 官方也提供了一些礼品支持。场地由上海对外经贸大学提供。
资金来源
详细记录
重新做了易拉宝，上次的越看越难看了：
冰箱贴 20 个：
贴纸 120 张：
社区展位礼品——我的书。自己另外带了两本，一共三本：
社区展位礼品——键盘咖啡：
一个道具话筒，本来想做采访但没做成：
7 个帖子 - 4 位参与者
]]>2025-09-20 09:00 (Asia/Shanghai) → 2025-09-20 18:00 (Asia/Shanghai)
开源松是什么？
开源松（Song of Open Source）是代码厨房社区自造的词语，可以理解为开源黑客松，但是又不必那么 hack，只是一场开源爱好者互相交流和共同参与开源项目的聚会活动。我们希望借助这个活动来鼓励和帮助大家参与开源项目、推动开源项目发展、孵化新的项目 idea。
如果你从来都没有参与过开源项目的话，这次活动也许会是你开源之路的第一步。你会认识其他喜欢编程和开源的朋友，和开源项目维护者们交流，顺便提交第一个开源贡献。
在其他项目报名之前，我们已经准备了两个代码厨房社区项目：
- FineWeather：一个 Vuejs+Python 实现的网络相册
GitHub - codekitchen-community/fine-weather: An album application. - APIFlask：Python Web API 框架
GitHub - apiflask/apiflask: A lightweight Python web API framework.
开源项目报名
如果你有自己的 Python 开源项目，欢迎报名参与！作为项目维护者，你可以在这里宣传你的项目，找到对你的项目感兴趣的人。访问下面的链接提交项目：
如果你想在开源松内分享关于你学习编程的小故事，或是想要组织一个编程工作坊，可以联系 @greyli。
代码厨房 x PyCon China 文艺汇演
去年，临时组建的代码厨房乐队在大会尾声带来了一场小小的表演。今年希望可以有更多不同的人加入我们。如果你喜欢唱歌，会一门乐器，或是有其他才艺，欢迎联系 @greyli 或留言报名。
大会报名
这次开源松将在 PyCon China 2025 内举办，报名大会即可参与（在下午开始的时候直接前往开源松会场）。今年 PyCon China 开放了免费票，访问下面的链接报名：
准备参加开源松的话，记得带上电脑。如果嫌电脑太沉的话，只是来看看热闹也同样欢迎。代码厨房同时也会布置展位，欢迎新老朋友来打声招呼。我们为你准备了一些贴纸和小礼品，记得来玩！
关于 PyCon China
PyCon China（中国 Python 开发者大会）自 2011 年首届大会起，每年由 PyChina 社区定期举办，现如今已成为中国大型的 Python 技术会议。这里汇集了来自整个 Python 生态的开发者和技术专家，旨在汇聚更多的开发者，一起交流 Python 技术，包括语言特性、开源项目、工程实践、运维测试、性能优化、创新应用等多个方面。
关于代码厨房
代码厨房是一个由编程和开源爱好者组成的社区。社区的主体是 https://codekitchen.community 网站。我们会不定期举办一些编程和开源相关的活动，希望可以让更多的人发现或重新发现编程的乐趣。访问 https://codekitchen.community/readme 阅读我们的社区 README。
4 个帖子 - 2 位参与者
]]>MultiAuth的支持了 
改动比较大，欢迎大家Code Review和提建议。
主要的改动有以下几点：
①将API Keys认证从Token认证里分离出来了
新版本：
auth = APIKeyHeaderAuth()
旧版本：
auth = HTTPTokenAuth('apiKey', header='X-API-Key')
之前API Keys认证使用HTTPTokenAuth的原因是：它的底层实现实际上是flask-httpauth的HTTPTokenAuth。
我查看了一下OpenAPI文档和其他资料，实际上API Keys可以位于查询参数（query parameters）、请求头或者cookie中。但是由于目前apiflask是使用的HTTPTokenAuth来实现API Keys认证，所以暂时只支持位于请求头中。
出于个人需求，apiflask后续可能会支持cookie认证。所以我先把它分离出来，为下一步的完整支持做准备。
旧用法仍然被兼容，但是会产生一个deprecation warning。
②把flask-httpauth的最低版本升级到了4.2.0
因为要支持MultiAuth的optional参数，所以flask-httpauth的最低版本被提升到了4.2.0。
在这个改动后，部分依赖版本不支持Python 3.8/3.9了…
如果不支持这个两个低版本，会对大家的使用造成影响，我建议这个功能等到3.0版本再发布
③security scheme的命名规则
修改当前的security scheme命名规则将会是破坏性的。所以我并没有实施，但是想在这里和大家讨论一下这个设计问题。
在当前版本中，如果security scheme的命名重复，apiflask会为其自动添加一个递增的后缀。
例如，当有两个认证类的security scheme被同时命名为"BasicAuth"时，在最终生成的OpenAPI文档中，第一个认证类的security schema名称是BasicAuth，第二个认证类的security scheme名称会被apiflask自动添加上一个后缀，被重命名为BasicAuth_2：
auth = HTTPBasicAuth(security_scheme_name='BasicAuth') # BasicAuth
auth2 = HTTPBasicAuth(security_scheme_name='BasicAuth') # BasicAuth_2
我认为目前的命名规则并不好：
- 擅自修改了用户输入：在用户不知情的情况下，修改了原本的security scheme名称
- 违背了清晰原则：“BasicAuth_2”这样的命名并不好，只是简单地回避了命名冲突，没有提供其他有效信息
- 增加了代码复杂性：代码实现需要检查命名是否冲突，并递推后缀（说实话，阅读和修改这段代码的时候有点痛苦…
）
目前我想到了两个方案：
- 在命名冲突时，产生警告或异常
- 后声明的命名覆盖掉先声明的命名
第二种方案参考自django-ninja。
django-ninja的security schema名称是直接使用的认证类的类名。例如，下面这个示例（不良示例，请勿模仿）中两个认证类的名称都为“APIKey”，但是一个位于查询参数中，一个位于请求头中。根据Python规则，后定义的类会覆盖先定义的类。所以最后生成的OpenAPI文档中，API Key会位于请求头中。
class APIKey(AuthCheck, APIKeyQuery):
pass
class APIKey(AuthCheck, APIKeyHeader):
pass
@api.get("/multiple", auth=[APIKey(), APIKey()])
def multiple(request):
return f"Token = {request.auth}"
10 个帖子 - 2 位参与者
]]>
4 个帖子 - 3 位参与者
]]>
当去掉0.1秒延迟，后台输出两次查询的数据库链接都为后一个请求对应的数据源，请问有什么好的方式实现动态切换数据源的问题吗
2 个帖子 - 2 位参与者
]]>