xiaohack's Blog - FastAPI
type: channel
link: https://blog.xiaohack.org/tag/fastapi/
items: 艾体宝干货 | 【Redis实用技巧#9】FastAPI + Redis + 滑动窗口：告别误伤，实现公平限流
items: LangGraph Server + AsyncPostgresSaver + unicorn 启动
items: zq-platform初始数据写不到数据库问题解决详细操作流程
items: Claude Code 支持重磅扩展 Skills —— 用最新 API 构建更靠谱的 AI 项目
items: [Show] 我复刻了微信，但把好友全换成了 AI：一个本地运行的虚拟社交沙盒
items: Claude Code × 智谱 BigModel 实战集成指南
items: 基于 Pydantic-Resolve 和 FastAPI-Voyager 的 Clean Architecture 实践 -- 一套面向复杂业务场景的 Python Web 开发方法论
items: 【开源自荐】匿名吃瓜平台「Instant Melon」，求佬们给点意见！

艾体宝干货 | 【Redis实用技巧#9】FastAPI + Redis + 滑动窗口：告别误伤，实现公平限流
type: item
date: 2026-02-04T11:25:21+08:00
description: 是否想设计一套让用户感到公平的 API 限流规则？通过平滑流量，避免随机触发 429 错误，并借助 Redis 与真正的滑动窗口算法，实现足够健壮的限流执行，以适应复杂的生产环境。如果限流器上线后立刻收到客诉，并非个例。事实上，大多数所谓“简单”的限流方案，其简单程度就如同将折叠椅当作简单梯子来用，平时凑合，但一旦出问题便可能是严重的故障，且往往发生在最不该出错的时刻。正确的解决方式不是提高限流阈值，而是让限流规则更具公平性。本文将演示如何为 FastAPI 与 Redis 搭建滑动窗口算法，避免边界峰值问题，减少误判，同时保持足以应对真实流量的性能。为什么固定窗口会导致误判？最常见的“固定窗口”算法，比如“每分钟最多 60 次请求”，看似简单有效，却隐藏着一个致命缺陷：假设一个用户在 12:00:59 这一刻瞬间发出了 60 次请求。紧接着下一秒 12:01:00，计数器清零重置。然后他又立刻发出 60 次请求。结果就是：在短短 1 秒多的时间里，用户实际发出了 120 次请求，而你的限流器却认为完全合规。更糟糕的是，固定窗口常常会惩罚那些在时间窗口边界附近正常操作的用户。比如用户在某一分钟的最后几秒和下一分钟的开头发送了两小批请求，就很容易被系统标记为“滥用”——即使他的行为完全没有恶意。滑动窗口算法正是为了解决这个问题而生的。滑动窗口是怎么工作的固定窗口问的是：“这个固定的 1 分钟时间段里，有多少请求？”滑动窗口问的是：“从当前这一刻往前推 60 秒，这滚动的 60 秒里，有多少请求？”它没有生硬的“时间桶”概念，也不会在整点时刻突然重置计数器。整个时间窗口是连续滑动的，就像一条移动的时间滑轨。有几种实现方式，但有一个非常优雅的 Redis 方案：存储：为每一个需要限流的对象（如用户ID、IP）创建一个 Redis 有序集合（ZSET），每次请求的时间戳就是集合中的一个成员。判断（每次请求时）：清理：移除集合中所有超过窗口时长（比如60秒）的旧时间戳。计数：统计集合中剩余的时间戳数量（即最近60秒内的请求数）。裁决：如果数量未超限，则将当前请求的时间戳加入集合。保洁：为这个集合设置一个过期时间，让不活跃的用户数据自动清理。核心架构：如何保证高并发下的准确性？[客户端请求] --> [FastAPI 应用 (依赖注入/中间件)] | |--- (原子化限流检查) ---| V [Redis 集群] (Key: 用户标识:路由路径) (Value: 有序集合 ZSET)这里的关键在于，“清理、计数、添加” 这一系列操作必须是原子的。否则，在超高并发下，多个请求可能同时通过检查，导致实际请求数超出限制。因此，我们选择使用 Redis Lua 脚本来保证原子性。设计限流键：我们要限制“谁”？在 coding 前，先定义“公平”的含义。按IP：最简单的方案，但对于公司网关、移动网络（NAT）后的多个真实用户可能不公平。按用户ID/API密钥：如果你有用户认证体系，这是最精准、最公平的方式。按端点：可以对不同的端点设置不同的限制，例如 /login 接口比 /public/news 更严格。复合键：例如 user_id:route，能实现非常精细的“公平使用”策略。一个推荐的实践策略是：首选：已认证用户的 API Key 或 User ID。降级：如果未认证，则使用 Client IP。增强：可选地结合请求路径，对不同成本的接口实施差异化限流。Redis Lua脚本（原子滑动窗口）这个脚本一次性完成了滑动窗口限流的所有逻辑：清理旧数据、判断是否超限、记录新请求。-- 参数说明：-- KEYS[1]: 限流键，例如 "rate_limit:user_123:/api/search"-- ARGV[1]: 当前时间戳（毫秒）-- ARGV[2]: 窗口大小（毫秒），如 60000-- ARGV[3]: 限制次数，如 60-- ARGV[4]: 键的过期时间（秒），应略大于窗口local current_time = tonumber(ARGV[1])local window_size = tonumber(ARGV[2])local max_requests = tonumber(ARGV[3])local key_ttl = tonumber(ARGV[4])-- 1. 移除窗口之外的所有旧时间戳 redis.call("ZREMRANGEBYSCORE", KEYS[1], 0, current_time - window_size)-- 2. 获取当前窗口内的请求数量local current_count = redis.call("ZCARD", KEYS[1])-- 3. 判断是否超限if current_count >= …

LangGraph Server + AsyncPostgresSaver + unicorn 启动
type: item
date: 2026-01-24T19:22:47+08:00
description: 使用 django 的 command 启动 langGraph Server, 但要求基于 AsyncPostgresSaver,没有找到相关的可用的代码, 这里记录下 直接抛出代码""" Run the LangGraph Agent Server """ import asyncio import uvicorn from django.core.management.base import BaseCommand from django.conf import settings from fastapi import FastAPI from fastapi.middleware.cors import CORSMiddleware from langserve import add_routes from langchain_core.globals import set_verbose from psycopg_pool import AsyncConnectionPool from langgraph.checkpoint.postgres.aio import AsyncPostgresSaver from apps.ai.graph.app import AsyncGraphApp class Command(BaseCommand): """ Run the LangGraph Agent Server """ help = "Starts the LangGraph Agent Server" def add_arguments(self, parser): parser.add_argument("--host", type=str, default="0.0.0.0") parser.add_argument("--port", type=int, default=2028) def handle(self, *args, **options): asyncio.run(self.handle_async(*args, **options)) async def handle_async(self, *args, **options): """启动 Agent Server""" host = options["host"] port = options["port"] self.stdout.write(f"Starting Agent Server at http://{host}:{port}...") # Get the LangGraph application checkpointer = await self.get_checkpointer() graph_app = AsyncGraphApp().compile(checkpointer=checkpointer).app print(f"graph_app----------------->: {graph_app}") # Initialize FastAPI app app = FastAPI( title="Baby Consultant Agent", version="1.0", description="A LangGraph-based agent for baby consultation", ) # Set CORS app.add_middleware( CORSMiddleware, allow_origins=["*"], allow_credentials=True, allow_methods=["*"], allow_headers=["*"], ) set_verbose(True) # Add routes using LangServe # This exposes the graph at /agent/invoke, /agent/stream, etc. add_routes( app, graph_app, path="/agent", ) # Run with Uvicorn config = uvicorn.Config(app, host=host, port=port) # 基于当前的Async Running Loop 启动unicorn server = uvicorn.Server(config) await server.serve() async def get_checkpointer(self): """获取 Checkpointer""" # 1. 显式创建连接池 (让它在应用生命周期内一直存活) connection_kwargs = { "autocommit…

LangGraph Server + AsyncPostgresSaver + unicorn 启动
type: item
date: 2026-01-23T18:19:32+08:00
description: 使用 django 的 command 启动 langGraph Server, 但要求基于 AsyncPostgresSaver,没有找到相关的可用的代码, 这里记录下 直接抛出代码""" Run the LangGraph Agent Server """ import asyncio import uvicorn from django.core.management.base import BaseCommand from django.conf import settings from fastapi import FastAPI from fastapi.middleware.cors import CORSMiddleware from langserve import add_routes from langchain_core.globals import set_verbose from psycopg_pool import AsyncConnectionPool from langgraph.checkpoint.postgres.aio import AsyncPostgresSaver from apps.ai.graph.app import AsyncGraphApp class Command(BaseCommand): """ Run the LangGraph Agent Server """ help = "Starts the LangGraph Agent Server" def add_arguments(self, parser): parser.add_argument("--host", type=str, default="0.0.0.0") parser.add_argument("--port", type=int, default=2028) def handle(self, *args, **options): asyncio.run(self.handle_async(*args, **options)) async def handle_async(self, *args, **options): """启动 Agent Server""" host = options["host"] port = options["port"] self.stdout.write(f"Starting Agent Server at http://{host}:{port}...") # Get the LangGraph application checkpointer = await self.get_checkpointer() graph_app = AsyncGraphApp().compile(checkpointer=checkpointer).app print(f"graph_app----------------->: {graph_app}") # Initialize FastAPI app app = FastAPI( title="Baby Consultant Agent", version="1.0", description="A LangGraph-based agent for baby consultation", ) # Set CORS app.add_middleware( CORSMiddleware, allow_origins=["*"], allow_credentials=True, allow_methods=["*"], allow_headers=["*"], ) set_verbose(True) # Add routes using LangServe # This exposes the graph at /agent/invoke, /agent/stream, etc. add_routes( app, graph_app, path="/agent", ) # Run with Uvicorn config = uvicorn.Config(app, host=host, port=port) # 基于当前的Async Running Loop 启动unicorn server = uvicorn.Server(config) await server.serve() async def get_checkpointer(self): """获取 Checkpointer""" # 1. 显式创建连接池 (让它在应用生命周期内一直存活) connection_kwargs = { "autocommit…

zq-platform初始数据写不到数据库问题解决详细操作流程
type: item
date: 2026-01-22T16:17:08+08:00
description: 我复现一下上面的操作说 zq-platform初始数据写不到数据库第一次执行alembic revision --autogenerate -m "init tables"报错INFO [ alembic.runtime.migration] Context impl PostgresqlImpl.INFO [ alembic.runtime.migration] Will assume transactional DDL.ERROR [ alembic.util.messaging] Target database is not up to date.FAILED: Target database is not up to date.意思是：你的数据库当前版本 (current) 落后于 Alembic 迁移脚本所定义的最新版本 (head) cnblogs.com+1。这就好比你手里拿着的是第3版的说明书，但产品已经更新到第5版了要解决这个问题，核心思路就是将数据库的当前版本 (current) 更新到与最新的迁移脚本版本 (head) 一致。1.查看当前数据库状态：首先，确认一下版本差异。在项目根目录下打开终端，依次运行： # 查看数据库当前记录的版本 alembic current # 查看所有可用的迁移脚本版本（head） alembic heads你通常会看到 current 的版本号比 heads 的版本号要旧，或者 heads 显示了多个分支（这通常意味着存在多个分支迁移需要合并）。分别显示INFO [ alembic.runtime.migration] Context impl PostgresqlImpl.INFO [ alembic.runtime.migration] Will assume transactional DDL.这证实了问题所在：数据库当前停留在一个空版本，并没有处于最新状态，所以 Alembic 拒绝你生成新的迁移脚本。请直接运行下面这条命令来解决这个问题：alembic upgrade head这个命令会扫描 alembic/versions 文件夹，找到所有脚本，并依次在数据库中执行它们。执行结果：INFO [ alembic.runtime.migration] Context impl PostgresqlImpl.INFO [ alembic.runtime.migration] Will assume transactional DDL.INFO [ alembic.runtime.migration] Running upgrade -> b6a31168d666, init tablesINFO [ alembic.runtime.migration] Running upgrade b6a31168d666 -> a79453452d83, add page design数据库已经成功升级到最新版本了。从输出 Running upgrade b6a31168d666 -> a79453452d83 可以看到：数据库已经更新到了 a79453452d83，打开数据库可以看到当前版本号：重新生成迁移：现在可以再次尝试运行 alembic revision --autogenerate -m “init tables”。alembic revision --autogenerate -m "init tables"显示结果：INFO [ alembic.runtime.migration] Context impl PostgresqlImpl.INFO [ alembic.runtime.migration] Will assume transactional DDL.Generating F:\下载程序与源码\★★★可执行项目收集★★★\zq-platform\backend-fastapi\alembic\versions\588 bd64ec92e_init_tables.py ... done输出显示：Generating ... 588bd64ec92e\_init\_tables.py ... done这表示 Alembic 成功扫描了你的代码和数据库，并发现它们之间的差异，自动生成了一个新的迁移脚本文件： 588bd64ec92e\_init\_tables.py。接下来的步骤：让修改生效现在脚本文件只是生成了，但数据库里的表结构还没变。你需要执行最后一步：1. 查看生成的脚本（可选，但推荐）你可以打开 alembic\versions\ 9abfcdbaff03\_init\_tables.py 看一眼。检查 upgrade() 函数里是否包含了 op.…

Claude Code 支持重磅扩展 Skills —— 用最新 API 构建更靠谱的 AI 项目
type: item
date: 2026-01-22T11:05:11+08:00
description: 在上一篇《Claude Code × 智谱 BigModel 实战集成指南》中，我们已经完成了一次完整的项目实战。项目可以正常运行，但在后续代码 Review 时，一个问题逐渐暴露出来：生成的代码虽然能跑，但大量 API 和用法已经过时，与最新官方文档存在明显偏差。这在 AI 辅助开发中其实非常常见——模型的训练数据更新速度，往往赶不上框架和 SDK 的迭代速度。正巧这时，一位朋友向我推荐了 Anthropic 最新发布的 Agent Skills，通过 plugins 的方式，让 Claude 在生成代码时 动态读取最新官方文档和工具能力，从而显著降低“写得像，但跑不通”的概率。本文就是这次探索的完整记录。一、Agent Skills 是什么？官方仓库地址：https://github.com/anthropics/skillsAgent Skills 可以理解为：一套可插拔的“能力模块”，用于教会 Claude 如何用正确的方法、最新的工具、可重复的流程 来完成特定任务。在技术层面上：每个 Skill 本质上是一个文件夹内部包含：指令（instructions）脚本（scripts）资源文件（resources）Claude Code 会在运行时动态加载这些 Skills它能解决什么问题？Agent Skills 的核心价值在于 “降低幻觉 + 提高一致性”，典型应用场景包括：按公司/团队的编码规范生成代码按最新官方文档调用 API（而不是靠模型记忆）执行固定的工程化流程（初始化项目、生成目录结构、部署脚本等）自动化个人或组织级任务简单来说：Skills 不是让模型更聪明，而是让模型更“守规矩”。二、在 Claude Code 中安装 Agent Skills在 Claude Code 命令行中执行：/plugin marketplace add anthropics/skills安装完成后，你就已经具备了使用官方 Skills 的能力。这一步相当于为 Claude Code 打开了“官方增强模式”。三、安装 context7 插件（关键步骤）接下来是本文的重点：context7。1️⃣ 打开插件管理在 Claude Code 中输入：/plugins然后使用键盘 ➡️ 进入 Discover。2️⃣ 搜索并安装 context7在搜索框中输入 context7，完成安装。context7 本质上是一个 MCP（Model Context Protocol）插件，能让 Claude 直接参考并对齐最新的官方文档内容。四、使用 context7 生成项目代码安装完成后，就可以在 Prompt 中显式声明使用 context7。示例 Prompt--- name: context7 description: 使用 Context7，基于框架最新的官方文档 --- # context7 ## 指南 已使用以下技术栈生成企业级项目： - 使用 Context7，基于最新的官方文档 - FastAPI 0.128.0，带 Token 认证 - 使用 sqlite 生成 token - 不使用 JWT，仅做 Token 校验 - langchain 1.2.6，使用 create_agent - langchain-ollama 1.0.1 - model：qwen3-vl:32b - embedding：qwen3-embedding:8b - langgraph 1.0.6 - Milvus（pymilvus）2.6.6 - langfuse 3.12.0通过这种方式，你是在明确告诉 Claude：不要靠“印象”写代码，而是以当前官方文档为准。五、实际体验与问题分析真实结论只有一句话：效果明显提升，但依然不能“一次生成直接可用”。优点API 使用明显更接近最新文档过时参数、废弃方法显著减少工程结构更合理，思路更偏向“真实项目”仍然存在的问题复杂技术栈组合（LangChain + LangGraph + Milvus + Langfuse）仍然需要 多轮调试才能完全跑通某些边界用法依然存在偏差我的判断并不是 context7 不行，而是模型生成速度，依然落后于框架演进速度。context7 做到的是：让 Claude 看得到 最新文档但最终“怎么拼起来”，仍然依赖模型本身的推理与代码能力六、总结如果你正在使用 Claude Code 做偏工程化、偏企业级的项目开发，我的建议是：✅ 一定要上 Agent Skills✅ 能用 context7 就用 context7❌ 不要再完全相信“模型记忆里的 API”但同时也要有一个清醒认知：AI 辅助开发 = 更快的起点，而不是免调试的终点。在当前阶段，最理想的模式依然是：AI 生成 + 人类…

[Show] 我复刻了微信，但把好友全换成了 AI：一个本地运行的虚拟社交沙盒
type: item
date: 2026-01-22T10:56:00+08:00
description: 大家好，我是 WeAgentChat (唯信) 的开发者。打开微信，那里是工作群的消息轰炸、亲戚的催婚和半生不熟的社交点赞。 有时候我在想，如果有一个平行的微信，里面所有的“好友”都是 AI ，但他们不仅能陪我聊天，还能像真人一样拥有性格、记得我们的点点滴滴，永远秒回、永远在线、永远站在我这边，那会是什么体验？于是，我撸出了这个 AI 版微信：WeAgentChat (唯信) 。👉 Talk is cheap, show me the code: GitHub | 官网 & 预览🌟 核心定义：你的另外一个微信WeChat 是给人类朋友的，WeAgentChat 是给 AI 朋友的。在这个应用里，我不仅刻意复刻了微信经典的 UI 风格和交互习惯（强迫症级别的还原），更试图打破目前 AI 助手“一问一答、用完即走”的工具属性，打造一个有温度的虚拟社交圈。1. 高度人格化的 Agent 矩阵你可以为每个 AI 好友设定独特的灵魂。他们不是通用的助手，而是拥有特定性格、背景故事甚至怪癖的“数字人类”。 有的可能是你的“毒舌损友”，在你犹豫不决时推你一把； 有的可能是“温和的长辈”，在你压力大时提供情绪价值。 2. 拒绝捏人焦虑：好友库 & 话题寻人不知道跟谁聊？懒得自己写 Prompt ？ 丰富的预设好友库：内置了数十位性格迥异的角色，从二次元老婆到硅谷大佬，一键添加，即刻开聊。 通过话题找名人：这是我最喜欢的功能。想聊“科幻小说”？系统自动为你推荐“刘慈欣”；想聊“烧脑电影”？“诺兰”直接出现在列表里。只需输入感兴趣的话题，系统会通过语义匹配找到最契合的 AI 聊伴。不再尬聊，直奔主题。 3. “双轨”长期记忆：它真的懂你大多数 AI 聊久了就会“失忆”，这种割裂感非常毁体验。我设计了一套双轨记忆系统： Global Profile：AI 会自动根据聊天内容，实时更新它对你的性格、喜好、现状的认知。 Event-Level RAG：每一段深刻的对话都会被蒸馏成“事件卡片”。即使你半年前随口提过一句失眠，今天它可能又会恰到好处地关心你的睡眠质量。 4. 被动会话管理：告别“新建聊天”我极其讨厌 ChatGPT 那种“手动点 New Chat”的割裂感。 在唯信里，如果你停止聊天超过 30 分钟，系统会自动归档当前会话并提取记忆。下次你再开口时，就像真朋友一样，是一个自然、连贯的新开始。5. 绝对自由的对话空间 (NSFW Friendly)我知道很多朋友苦于大厂模型的道德审查。 得益于本地化架构，你可以自由接入无审查模型（如各类 Uncensored 本地模型或 API ）。在这里，没有云端审判，你可以聊任何想聊的话题，释放最真实的压力。🛠️ 硬核技术实现 (V 站惯例)作为一个本地优先的应用，我选择了最稳健的工具链： Frontend: Vue 3.5 + Vite + Tailwind CSS (UI 高度还原微信风格)。 Backend: FastAPI (Python) 异步驱动。 Database: SQLite + sqlite-vec (所有的向量存储和关系数据都在本地，隐私第一)。 Memory Engine: 嵌入式 Memobase SDK ，处理复杂的事件提取和 RAG 检索。 Desktop: Electron 包装，支持一键启动后端服务。 🔒 隐私与安全这可能是我做这个产品最坚持的一点：所有聊天记录和记忆数据都保存在你本地的 sqilte 数据库中。 你可以连接 OpenAI （兼容） 的 API 。除了 LLM 和向量化的调用，没有任何数据会上传到云端。💡 开发小花絮：Vibe Coding 时代的产物说起来，这个项目的诞生还要感谢现在的 AI 编程浪潮。 每天在公司上班，我已经习惯了 Vibe Coding 的节奏：把繁杂的逻辑丢给 AI ，看着它在屏幕上飞速吐代码。 在等待 AI 生成代码的那几十秒、几分钟的“贤者时间”里，我不仅没闲着，反而以此为契机，并行开启了这个 Side Project 。 用 AI 帮我省下的时间，去创造另一个全是 AI 的世界，这大概就是程序员独有的浪漫（摸鱼）吧。💬 邀请与反馈目前项目还在活跃开发中，核心的对话流和记忆系统已经跑通。我想听听大家的看法： 如果拥有这样一个“另外的微信”，你最希望在这里和什么样的 AI 交朋友？ 在“人与 AI 深度社交”这个命题下，你最看重的功能是什么？ 目前的 UI 预览欢迎拍砖，也欢迎给个 Star 鼓励一下社恐开发者的奇思妙想。

Claude Code × 智谱 BigModel 实战集成指南
type: item
date: 2026-01-20T09:47:54+08:00
description: Claude Code × 智谱 BigModel 实战集成指南本文记录一次 Claude Code + 智谱 BigModel（GLM Coding 套餐） 的完整体验，从 CLI 安装、IDE 集成，到使用 Claude Code 零手写代码 搭建一个可运行的 AI 后端工程，并对整体体验做一个总结。一、什么是 Claude Code？Claude Code 是 Anthropic 推出的 本地 AI 编码助手（CLI + IDE 插件），核心能力包括：在本地代码仓库中直接对话式开发理解项目结构、自动生成/修改代码支持多种 IDE（VS Code / JetBrains 全家桶）支持通过 兼容 Anthropic API 的第三方模型 接入（如智谱 GLM）这意味着：即使不使用 Anthropic 官方模型，也可以完整使用 Claude Code 的工程化能力。二、Claude Code CLI 安装macOS / Linux / WSLcurl -fsSL https://claude.ai/install.sh | bashWindows PowerShellirm https://claude.ai/install.ps1 | iexWindows CMDcurl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd安装完成后，终端中可直接使用：claude三、IDE 集成能力1️⃣ Claude Code Desktop官方桌面客户端适合直接在本地项目中进行对话式开发2️⃣ VS Code官方插件支持与当前 Workspace 深度绑定3️⃣ JetBrains 系列（官方支持）IntelliJ IDEAPyCharmGoLandWebStormPhpStormAndroid Studio实际体验中，对 多文件工程、后端项目结构 的理解能力非常强。四、接入智谱 BigModel（GLM Coding 套餐）Claude Code 可以通过 Anthropic API 兼容协议 接入智谱大模型。4.1 注册账号👉 https://www.bigmodel.cn/glm-coding4.2 创建 API Key登录后进入：👉 https://bigmodel.cn/usercenter/proj-mgmt/apikeys创建新的 API Key 并保存。4.3 使用官方自动化工具（强烈推荐）智谱提供了 Coding Tool Helper，可自动完成：Claude Code 安装API Key 配置MCP Server 管理模型套餐加载一条命令完成配置npx @z_ai/coding-helper按照交互提示操作即可，无需手动修改复杂配置。4.4 启动 Claude Code进入任意代码目录，执行：claude首次启动时若提示：Do you want to use this API key?选择 Yes 即可。五、模型配置与切换默认模型映射ANTHROPIC_DEFAULT_OPUS_MODEL → GLM-4.7 ANTHROPIC_DEFAULT_SONNET_MODEL → GLM-4.7 ANTHROPIC_DEFAULT_HAIKU_MODEL → GLM-4.5-Air手动配置（可选）编辑文件：~/.claude/settings.json{ "env": { "ANTHROPIC_DEFAULT_HAIKU_MODEL": "glm-4.5-air", "ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-4.7", "ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-4.7" } }验证模型状态重新打开终端并运行：claude在 Claude Code 中输入：/status即可看到当前模型配置状态。六、资源包与福利✅ 注册即送 体验 Token✅ 实名认证赠送 500 万 GLM-4.7 Token👉 资源包管理：https://bigmodel.cn/finance-center/resource-package/package-mgmt对于个人开发者和技术验证阶段非常友好。七、实战体验：零手写代码搭建 AI 后端在 Claude Code 中直接输入需求：请帮我集成 FastAPI、LangChain、LangGraph、langchain-ollama、Milvus，并构建好项目结构：FastAPI 接口Token 认证（非 JWT）使用 SQLite 生成和校验 TokenMilvus 作为向量数据库Ollama 作为本地模型推理结果…

基于 Pydantic-Resolve 和 FastAPI-Voyager 的 Clean Architecture 实践 -- 一套面向复杂业务场景的 Python Web 开发方法论
type: item
date: 2026-01-19T16:01:25+08:00
description: 基于 Pydantic-Resolve 和 FastAPI-Voyager 的 Clean Architecture 实践篇幅较长无法粘贴全文，原文链接： https://github.com/allmonday/A-Python-web-development-methodology-for-complex-business-scenarios/blob/main/README.zh.md一套面向复杂业务场景的 Python Web 开发方法论目录 基于 Pydantic-Resolve 和 FastAPI-Voyager 的 Clean Architecture 实践 目录 1. 背景与问题 1.1 当前主流做法及其痛点 [模式一：直接使用 ORM （如 SQLAlchemy ）](#模式一直接使用-orm 如-sqlalchemy) 模式二：使用 ORM 的 Eager Loading 模式三：手动组装数据 模式四：使用 GraphQL 1.2 问题根源分析 [问题 1：业务模型与数据模型混淆](#问题-1 业务模型与数据模型混淆) [问题 2：依赖方向错误](#问题-2 依赖方向错误) [问题 3：缺少业务关系的显式声明](#问题-3 缺少业务关系的显式声明) [问题 4：中间表的技术暴露](#问题-4 中间表的技术暴露) 2. Clean Architecture 思想 2.1 核心原则 [原则 1：依赖规则](#原则-1 依赖规则) [原则 2：业务规则独立](#原则-2 业务规则独立) [原则 3：跨边界的数据传递](#原则-3 跨边界的数据传递) 2.2 依赖规则 2.3 在 Web 开发中的应用 传统架构的问题 [3. Pydantic-Resolve：业务模型层](#3-pydantic-resolve 业务模型层) 3.1 核心概念 核心思想 [3.2 ERD：业务关系的声明](#32-erd 业务关系的声明) 定义实体关系图 ERD 的关键特性 [3.3 DataLoader：批量加载的秘密](#33-dataloader 批量加载的秘密) [问题：N+1 查询](#问题 n1-查询) [解决方案：DataLoader](#解决方案 dataloader) [DefineSubset：字段选择与复用](#definesubset 字段选择与复用) [3.4 Resolve 与 Post：数据组装与计算](#34-resolve-与-post 数据组装与计算) [Resolve：声明数据依赖](#resolve 声明数据依赖) [Post：数据后处理](#post 数据后处理) 3.5 跨层数据传递 [Expose：父节点向子节点暴露数据](#expose 父节点向子节点暴露数据) [Collect：子节点向父节点收集数据](#collect 子节点向父节点收集数据) 3.6 小结 [4. FastAPI-Voyager：架构可视化](#4-fastapi-voyager 架构可视化) 4.0 为什么需要架构可视化？ 4.1 核心功能 1. 自动扫描 API 结构 2. 三层架构展示 4.2 ERD 与 API Route 的结合 核心：业务-技术映射图 4.3 实战应用场景 [场景 1：发现架构偏离](#场景-1 发现架构偏离) [场景 2：发现过度嵌套](#场景-2 发现过度嵌套) [场景 3：新人快速理解系统](#场景-3 新人快速理解系统) 5. 完整的开发流程 5.1 架构设计阶段 [步骤 1：识别核心业务实体](#步骤-1 识别核心业务实体) [步骤 2：定义实体关系](#步骤-2 定义实体关系) 5.2 实体定义阶段 定义 ERD 5.3 数据层实现 [定义 ORM Models （以 ERD 为指导）](#定义-orm-models 以-erd-为指导) 实现 Loaders 5.4 API 实现阶段 定义 Response Models 实现 API Routes 5.5 可视化验证 集成 FastAPI-Voyager 验证架构 6. 与其他方案的对比 6.1 vs 传统 ORM 6.2 vs GraphQL 6.3 vs DDD 框架 7. 总结 核心价值 1. 业务模型优先 2. Clean Architecture 实现 3. 自动性能优化 4. 架构可视化 5. 开发效率提升 6. 更易测试和调试 适用场景 推荐使用 不推荐使用 结语 参考资料 1. 背景与问题1.1 当前主流做法及其痛点在 Python Web 开发中，处理复杂业务场景时，开发者通常采用以下几种模式：模式一：直接使用 ORM （如 SQLAlchemy ）@router.get("/teams/{team_i…

基于 Pydantic-Resolve 和 FastAPI-Voyager 的 Clean Architecture 实践 -- 一套面向复杂业务场景的 Python Web 开发方法论
type: item
date: 2026-01-17T21:57:04+08:00
description: 基于 Pydantic-Resolve 和 FastAPI-Voyager 的 Clean Architecture 实践篇幅较长无法粘贴全文，原文链接： https://github.com/allmonday/A-Python-web-development-methodology-for-complex-business-scenarios/blob/main/README.zh.md一套面向复杂业务场景的 Python Web 开发方法论目录 基于 Pydantic-Resolve 和 FastAPI-Voyager 的 Clean Architecture 实践 目录 1. 背景与问题 1.1 当前主流做法及其痛点 [模式一：直接使用 ORM （如 SQLAlchemy ）](#模式一直接使用-orm 如-sqlalchemy) 模式二：使用 ORM 的 Eager Loading 模式三：手动组装数据 模式四：使用 GraphQL 1.2 问题根源分析 [问题 1：业务模型与数据模型混淆](#问题-1 业务模型与数据模型混淆) [问题 2：依赖方向错误](#问题-2 依赖方向错误) [问题 3：缺少业务关系的显式声明](#问题-3 缺少业务关系的显式声明) [问题 4：中间表的技术暴露](#问题-4 中间表的技术暴露) 2. Clean Architecture 思想 2.1 核心原则 [原则 1：依赖规则](#原则-1 依赖规则) [原则 2：业务规则独立](#原则-2 业务规则独立) [原则 3：跨边界的数据传递](#原则-3 跨边界的数据传递) 2.2 依赖规则 2.3 在 Web 开发中的应用 传统架构的问题 [3. Pydantic-Resolve：业务模型层](#3-pydantic-resolve 业务模型层) 3.1 核心概念 核心思想 [3.2 ERD：业务关系的声明](#32-erd 业务关系的声明) 定义实体关系图 ERD 的关键特性 [3.3 DataLoader：批量加载的秘密](#33-dataloader 批量加载的秘密) [问题：N+1 查询](#问题 n1-查询) [解决方案：DataLoader](#解决方案 dataloader) [DefineSubset：字段选择与复用](#definesubset 字段选择与复用) [3.4 Resolve 与 Post：数据组装与计算](#34-resolve-与-post 数据组装与计算) [Resolve：声明数据依赖](#resolve 声明数据依赖) [Post：数据后处理](#post 数据后处理) 3.5 跨层数据传递 [Expose：父节点向子节点暴露数据](#expose 父节点向子节点暴露数据) [Collect：子节点向父节点收集数据](#collect 子节点向父节点收集数据) 3.6 小结 [4. FastAPI-Voyager：架构可视化](#4-fastapi-voyager 架构可视化) 4.0 为什么需要架构可视化？ 4.1 核心功能 1. 自动扫描 API 结构 2. 三层架构展示 4.2 ERD 与 API Route 的结合 核心：业务-技术映射图 4.3 实战应用场景 [场景 1：发现架构偏离](#场景-1 发现架构偏离) [场景 2：发现过度嵌套](#场景-2 发现过度嵌套) [场景 3：新人快速理解系统](#场景-3 新人快速理解系统) 5. 完整的开发流程 5.1 架构设计阶段 [步骤 1：识别核心业务实体](#步骤-1 识别核心业务实体) [步骤 2：定义实体关系](#步骤-2 定义实体关系) 5.2 实体定义阶段 定义 ERD 5.3 数据层实现 [定义 ORM Models （以 ERD 为指导）](#定义-orm-models 以-erd-为指导) 实现 Loaders 5.4 API 实现阶段 定义 Response Models 实现 API Routes 5.5 可视化验证 集成 FastAPI-Voyager 验证架构 6. 与其他方案的对比 6.1 vs 传统 ORM 6.2 vs GraphQL 6.3 vs DDD 框架 7. 总结 核心价值 1. 业务模型优先 2. Clean Architecture 实现 3. 自动性能优化 4. 架构可视化 5. 开发效率提升 6. 更易测试和调试 适用场景 推荐使用 不推荐使用 结语 参考资料 1. 背景与问题1.1 当前主流做法及其痛点在 Python Web 开发中，处理复杂业务场景时，开发者通常采用以下几种模式：模式一：直接使用 ORM （如 SQLAlchemy ）@router.get("/teams/{team_i…

【开源自荐】匿名吃瓜平台「Instant Melon」，求佬们给点意见！
type: item
date: 2026-01-14T10:59:41+08:00
description: Instant Melon (即刻瓜田)一个专注于匿名故事分享与互动的开源平台。“每个人都有故事，这里是你的树洞，也是你的瓜田。” 项目简介最近闲来无事（忘记在哪刷到了一个类似的平台），就 A 了一个匿名吃瓜平台。起因是想做一个纯粹的、无压力的吐槽和分享空间。项目目前已经开源，欢迎各位佬品鉴。给我一些优化建议。如果觉得还不错，求一个宝贵的 Star！GitHub 地址： https://github.com/AIME-JF/Instant-Melon在线地址：Instant-Melon 核心功能匿名发布：无需复杂的注册流程（匿名），保护隐私，畅所欲言。吃瓜互动：支持评论、双击点赞、表情互动，让吃瓜更有趣。清新 UI：精心设计的界面，适配移动端与桌面端，阅读体验极佳。内容管理：内置简单的审核机制，防止滥用。前端框架：Next.js (App Router) / Vue3UI 组件：TailwindCSS / ShadcnUI后端 / 数据库： PostgreSQL / FastAPI（PS：现在没啥内容在里面，因为根本没人玩 ，有几个内容是搬站内佬的） 快速开始 / 部署git clone [https://github.com/AIME-JF/Instant-Melon.git](https://github.com/AIME-JF/Instant-Melon.git) 📌 转载信息来源： https://linux.do/t/topic/1441580转载时间： 2026/1/14 10:59:40