freeCodeCamp 每日编程挑战解析Blood Bank 血库配型问题与贪心分配算法【免费下载链接】freeCodeCampfreeCodeCamp.orgs open-source codebase and curriculum. Learn math, programming, and computer science for free.项目地址: https://gitcode.com/GitHub_Trending/fr/freeCodeCamp本文聚焦 freeCodeCamp 开源仓库中每日编程挑战Daily Coding Challenges序列的第 320 道题「Blood Bank」完整拆解题目规则、血型兼容模型、参考解法中的贪心策略与优先级设计并结合仓库源码说明该类挑战在课程结构、数据库播种与 API 层中的实际落地方式。读完本文你将掌握如何把多对多资源分配问题建模为带优先级的贪心匹配并理解 freeCodeCamp 每日挑战从 Markdown 题库到线上题目的完整链路。挑战全景第 320 道每日编程挑战「Blood Bank」是daily-coding-challenges-javascript课程块block中的第 320 道题其原始文档位于 curriculum/challenges/english/blocks/daily-coding-challenges-javascript/6a15cadf5f240d05a264955e.md。从该文档的 frontmatter 可以看到id: 6a15cadf5f240d05a264955e title: Challenge 320: Blood Bank challengeType: 28 dashedName: challenge-320其中challengeType: 28在 packages/shared/src/config/challenge-types.ts 中被定义为dailyChallengeJs第 30 行相邻的29对应dailyChallengePy。这意味着每一道每日挑战都以 JavaScript、Python 双语言形态存在而本文分析的 Markdown 文件正是 JavaScript 版本的题库源。整个块共包含 365 道题对应全年每天一题由 curriculum/structure/blocks/daily-coding-challenges-javascript.json 中的challengeOrder数组按id引用Blood Bank 的 id6a15cadf5f240d05a264955e就出现在该数组中。块的配置还声明了usesMultifileEditor: true、helpCategory: JavaScript与disableLoopProtectTests: true说明这类题在答题界面上使用多文件编辑器、归类为 JavaScript 帮助类别并关闭了循环保护检测以允许更自由的循环写法。问题描述与输入输出约定题目的核心描述来自文档# --description--段如下给定一个表示血库库存的血型数组和一个表示患者血型需求的数组返回形如X of Y patients served的字符串。其中X是库存能够满足的最大患者人数Y是患者总人数。两个数组中的每个元素都只能是以下四种血型之一AB、A、B、O。bank库存数组每个重复元素代表一单位库存血patients患者数组每个重复元素代表一位需要该血型的患者返回值X of Y patients served例如4 of 4 patients served。要求实现的函数签名为triageBlood(bank, patients)题目给出的初始种子代码# --seed-contents--为function triageBlood(bank, patients) { return bank; }即学习者需要把占位实现替换为真正的配型逻辑。血型兼容性模型题目的配型规则非常明确文档原文患者血型可接受的血型供体灵活程度AB任意血型AB、A、B、O最灵活通用受血者AA、O中等BB、O中等O仅O最受限这里存在两个关键不对称O是最紧缺的资源它既能被O患者使用也能被A、B、AB三类患者使用但O患者本身只能使用O血AB患者最不挑任何血型都能满足他们因此他们应当最后再被服务。这种资源被多种需求方争夺、而其中一类需求方别无选择的结构正是贪心分配问题的典型特征——越受限制的需求越要先满足。算法设计带优先级的贪心分配核心思路要最大化服务患者总数直观的策略是先服务血型最受限的患者并且在同一类患者内部优先消耗特异性更高的血液把通用血型O留到后面。仓库中的参考解法# --solutions--段正是按如下优先级处理O患者 → 只从O库存中取血A患者 → 先取A不足再取OB患者 → 先取B不足再取OAB患者 → 依次取AB、A、B、O。这样设计的原因是O血可以满足四种患者如果过早把它消耗在A/B/AB患者身上后续遇到只能输O的O患者时就会无血可用导致整体服务人数下降。反过来把最挑剔的O患者优先安排把最不挑剔的AB患者安排到最后吃剩余库存才能逼近最大服务人数。参考实现逐行拆解仓库文档# --solutions--中给出的完整参考实现如下function triageBlood(bank, patients) { const b {}; const p {}; for (const t of bank) b[t] (b[t] || 0) 1; for (const t of patients) p[t] (p[t] || 0) 1; const serve (patient, donors) { for (const donor of donors) { const n Math.min(p[patient] || 0, b[donor] || 0); p[patient] (p[patient] || 0) - n; b[donor] (b[donor] || 0) - n; saved n; } }; let saved 0; serve(O, [O]); serve(A, [A, O]); serve(B, [B, O]); serve(AB, [AB, A, B, O]); return ${saved} of ${patients.length} patients served; }可以拆成三个阶段理解第一步统计数量。用两个普通对象b与p分别对库存和患者做计数频次统计(b[t] || 0) 1这种写法在键不存在时按 0 处理是典型的计数惯用法。由于血型只有 4 种对象始终只有不超过 4 个键等价于一个固定大小的映射。第二步定义服务闭包。内部函数serve(patient, donors)按传入的供体优先级列表依次尝试n Math.min(p[patient] || 0, b[donor] || 0)计算本轮最多能匹配的单位数患者剩余需求与对应库存的较小者同步扣减患者剩余需求p[patient]与库存b[donor]把n累加到外部变量saved上。注意serve内部引用的是外层声明的let saved这正是闭包捕获外部变量的典型用法saved的声明位置在serve定义之后、调用之前也符合先定义函数、后初始化计数的代码组织方式。第三步按优先级调度。依次对O、A、B、AB四类患者执行serve供体列表的顺序即先用特异性强的、后用通用血的贪心顺序。最终返回模板字符串${saved} of ${patients.length} patients served。为什么贪心在这里是安全的对这道题而言血型只有 4 类、兼容关系是单向偏序O最底层、AB最顶层因此按受限程度从高到低、供体按特异性从高到低的贪心顺序即可得到最优解。这种先服务受限方、再服务灵活方的思想可以推广到更一般的资源分配问题例如有限通用资源 多种专用替代品的库存调度场景。测试用例验证题目在# --hints--段给出了 6 组测试断言全部使用assert.equal校验返回值。逐一推演如下用例 1库存与需求完全匹配triageBlood([O, A, B, AB], [O, A, B, AB]) // 4 of 4 patients served每种血型库存 1 单位、需求 1 人一一对应4 位患者全部服务返回4 of 4 patients served。用例 2缺乏 O 血导致的缺口triageBlood([A, A, B, B, AB], [O, A, B, B, B]) // 3 of 5 patients served库存中没有O因此O患者无法被服务A患者消耗 1 单位A两位B患者各消耗 1 单位B后第 3 位B患者无血可输O库存为 0。最终只服务 3 人验证了O 患者必须优先、且无 O 血即无法服务的规则。用例 3全 AB 患者吃干库存triageBlood([O, A, B, AB], [AB, AB, AB, AB, AB]) // 4 of 5 patients served5 位AB患者面对 4 单位任意血型库存。由于O、A、B患者数为 0前两步跳过最后AB患者按AB → A → B → O顺序把 4 单位库存全部消耗服务 4 人、1 人无血验证了AB 患者最灵活、最后服务的设计。用例 4只有 O 血却能服务所有患者triageBlood([O, O, O, O, O], [O, A, B, AB]) // 4 of 4 patients served5 单位O血依次服务 1 位O、1 位A、1 位B、1 位AB患者4 人全部满足返回4 of 4 patients served直观展示了O作为通用供血者的价值。用例 5混合场景下的资源竞争triageBlood([A, O, B, AB, B, AB, O, A, A], [O, A, B, AB, A, B, A, A, B, A, B]) // 8 of 11 patients served库存统计为 A:3、O:2、B:2、AB:2需求为 O:1、A:5、B:4、AB:1。按优先级O 患者消耗 1 单位 OA 患者先消耗 3 单位 A、再消耗 1 单位 O共 4 人B 患者消耗 2 单位 B共 2 人AB 患者消耗 1 单位 AB。合计 8 人剩余 3 位患者1 位 A、2 位 B无血可输。用例 6长数组的完整调度triageBlood([O, B, AB, AB, O, A, A, AB, O, B, B, AB, A, B, AB], [O, A, B, B, A, B, AB, A, B, A, O, AB, AB, O]) // 13 of 14 patients served库存为 O:3、A:3、B:4、AB:5需求为 O:3、A:4、B:4、AB:3。O 患者消耗全部 3 单位 OA 患者消耗 3 单位 A 后仍缺 1 人O 已耗尽B 患者消耗 4 单位 B 全部满足AB 患者消耗 3 单位 AB。合计 13 人仅剩 1 位 A 患者无法服务。若在 A 患者之前就消耗 O 血服务人数只会更少这组用例验证了O 血必须留给最需要的场景的贪心正确性。复杂度分析时间复杂度统计阶段各遍历一次bank与patients为O(n m)n为库存长度、m为患者长度服务阶段对 4 类患者各迭代至多 4 种供体为常数O(16)。总体为线性时间。空间复杂度两个计数对象最多各含 4 个键为O(1)额外空间与输入规模无关。边界情况与扩展思考空数组bank或patients为空时循环不执行saved为 0返回如0 of 0 patients served空库存配空需求或0 of 3 patients served有需求无库存行为由代码自然保证。库存充足但血型错配例如只有A血而患者全为O时服务数为 0符合O 只能接受 O的规则。通用受血者的兜底价值AB患者几乎不会成为瓶颈除非完全没有库存这使它在调度中天然处于吃剩余位置。算法推广把血型换成通用组件 专用组件、把患者换成需求规格同一套受限优先 通用资源保底的贪心框架即可复用到库存管理、座位分配、带宽预留等真实业务。在 freeCodeCamp 项目中的落地链路「Blood Bank」不是孤立的一道题它背后是 freeCodeCamp 每日编程挑战的完整工程链路仓库中可找到以下实现证据1. 课程块与顺序定义curriculum/structure/blocks/daily-coding-challenges-javascript.json 定义了块的 365 道题顺序Challenge 320: Blood Bank及其 id6a15cadf5f240d05a264955e位于其中。块的元数据usesMultifileEditor: true、disableLoopProtectTests: true等字段需要符合 curriculum/schema/challenge-schema.js 中的 Joi 校验规则如blockLayout合法取值、helpCategory枚举、challengeType范围等。2. 类型与语言映射packages/shared/src/config/challenge-types.ts 中dailyChallengeJs 28、dailyChallengePy 29并由getIsDailyCodingChallenge与getDailyCodingChallengeLanguage提供是否每日挑战、对应哪种语言的判定客户端据此渲染 JavaScript/Python 双语言编辑器。3. 数据库播种tools/daily-challenges/seed-daily-challenges.ts 是每日挑战的播种脚本通过 GraphQL 从 dev-playground 超级块拉取题目数据校验 JavaScript 与 Python 题目数量一致且等于 365然后按固定的起始日期2025-08-11脚本内硬校验不可更改逐日分配date写入 MongoDB 的DailyCodingChallenges集合。4. API 查询层api/src/daily-coding-challenge/routes/daily-coding-challenge.ts 暴露了GET /daily-coding-challenge/date/:date、/day/:day、/today、/month/:month、/all、/newest等只读接口响应结构id、date、challengeNumber、title、description、javascript、python由 api/src/daily-coding-challenge/schemas/daily-coding-challenge.ts 中的 TypeBox schema 约束其中javascript.tests与challengeFiles正是本题# --hints--与# --seed-contents--在运行时系统中的载体。5. 客户端校验与端到端测试客户端通过 client/src/utils/daily-coding-challenge-validator.ts 对 API 返回的挑战数据做 Joi 二次校验含tests、challengeFiles结构e2e/daily-coding-challenge.spec.ts 则以 Playwright 模拟真实浏览器流程验证每日挑战页面的加载、JavaScript/Python 切换等行为。因此阅读这道 Blood Bank 题目时你看到的不只是 6 组断言和一个参考解法而是 freeCodeCampMarkdown 题库 → 结构化校验 → 数据库播种 → API 下发 → 前端作答的完整工程闭环中的一个环节。理解这道题的贪心思想后你也可以沿着上述文件路径继续探索其余 364 道每日挑战的解法风格或深入每日挑战 API 的查询与缓存机制。【免费下载链接】freeCodeCampfreeCodeCamp.orgs open-source codebase and curriculum. Learn math, programming, and computer science for free.项目地址: https://gitcode.com/GitHub_Trending/fr/freeCodeCamp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考