agent学习Day7——依赖注入、中间件与 LLM 服务化

一、依赖注入Depends让依赖不再写死为什么需要依赖注入之前项目里analyze_jd()这类能力和配置是绑死的谁要用谁就from app.core.config import settings自己读一遍.env甚至函数内部直接import写死配置。问题有三重复浪费每个路由都自己读配置、自己初始化代码抄好几遍。耦合函数把读配置和做业务搅在一起一处出错全链路连坐。没法测配置写死在模块里想换成假配置只能 mock 整个模块很脏。FastAPI 的Depends把这件事翻转过来——依赖不再自己import而是别人喂进来外部注入。怎么用写一个普通函数返回依赖对象路由参数声明Depends(...)请求进来时 FastAPI 自动调用该函数并把返回值塞进参数# app/api/dependencies.pyfromapp.core.configimportSettings,settingsdefget_settings()-Settings:returnsettingsdefget_llm_service()-LlmService:returnLlmService(settings)# app/main.py 的 /healthfromapp.api.dependenciesimportget_settingsfromapp.core.configimportSettingsdefhealth(settings:SettingsDepends(get_settings)):returnHealthResponse(app_namesettings.APP_NAME,...)关键注意点settings的类型注解需要写Settings类大写而实际传入的值由Depends(get_settings)注入因此main.py里只需from app.core.config import Settings不必再import settings实例——类型与实例来源是两回事不要混为一谈。二、中间件Middleware给所有请求统一插一脚为什么需要中间件想记录每个请求花了多久如果在每个路由里手写time.time()重复代码一堆漏写一个就缺数据。中间件是 FastAPI 给的请求前后自动执行一段代码的机制——它包在所有路由外面每个请求都经过。怎么写# app/api/middleware.pyimportloggingimporttime loggerlogging.getLogger(__name__)asyncdeflog_request_time(request,call_next):starttime.time()responseawaitcall_next(request)# 真正执行路由duration_ms(time.time()-start)*1000logger.info(f{request.method}{request.url.path}took{duration_ms:.2f}ms)returnresponse# app/main.py在 app FastAPI() 之后注册fromapp.api.middlewareimportlog_request_time app.middleware(http)(log_request_time)执行顺序请求进 → 记开始时间 → call_next 跑路由 → 拿到 response → 算耗时打日志 → 返回。关键注意点注意日志不打印的问题代码明明执行了终端却看不到耗时日志。根因是 Pythonlogging默认级别是WARNING而中间件用logger.info(...)INFO级别低于WARNING会被直接吞掉更隐蔽的是logging.basicConfig(...)会被uvicorn 启动时覆盖root logger 级别被抬回WARNING。修复方式是显式设置 root logger 并兜底添加 handlerimportlogging root_loggerlogging.getLogger()root_logger.setLevel(logging.INFO)ifnotroot_logger.handlers:handlerlogging.StreamHandler()handler.setFormatter(logging.Formatter(%(asctime)s - %(name)s - %(levelname)s - %(message)s))root_logger.addHandler(handler)三、从函数到类LLM 服务化LlmService为什么改成类之前的call_llm()是模块级函数client OpenAI(...)在模块被 import 的那一刻就执行了——只要.env里 key 少一行任何 import 它的路由一加载就崩/health都起不来。改成LlmService类带来三层好处操作与数据绑定settings存成self.settings方法随用随取不用每次拎参数。可测试__init__(settings)外部传入测试时LlmService(fake_settings)一行搞定呼应前面的Depends注入思想。延迟创建client挪进__init__只有真实例化时才建连接模块能正常 import不再连坐崩溃。改造后的骨架classLlmService:def__init__(self,settings:Settings):self.settingssettings self.clientOpenAI(api_keysettings.DEEPSEEK_API_KEY,base_urlsettings.DEEPSEEK_BASE_URL,)defcall_llm(self,prompt:str,system_prompt:str,temperature:float|NoneNone)-str:iftemperatureisNone:temperatureself.settings.LLM_TEMPERATURE# ... 用 self.client / self.settings.LLM_MODEL / MAX_TOKENS / TIMEOUT ...returncontentdefanalyze_jd(self,jd_text:str)-JdAnalysisResult:user_promptbuild_jd_user_prompt(jd_text)rawself.call_llm(promptuser_prompt,system_promptSYSTEM_PROMPT_JD,temperature0)returnparse_jd_analysis(raw)同时给config.py补了LLM_TEMPERATURE/LLM_MAX_TOKENS/LLM_TIMEOUT三个字段让调用参数全部来自配置而非硬编码。路由层接入新接口/api/v1/jd/analyze-basic-llm只干三件事收请求 → 注入的llm_service.analyze_jd()→ 返回JdAnalysisResult。llm_service不是import死的而是Depends(get_llm_service)注入的router.post(/analyze-basic-llm,response_modelJdAnalysisResult)defanalyze_basic_llm(req:JdAnalyzeRequest,llm_service:LlmServiceDepends(get_llm_service),):returnllm_service.analyze_jd(req.jd_text)四、pytest dependency_overrides用测试证明注入有用为什么写这个测试依赖注入的可替换好处不能只靠嘴说要测试证明。FastAPI 给了一把钥匙app.dependency_overrides。fromfastapi.testclientimportTestClientfromapp.api.dependenciesimportget_settingsfromapp.core.configimportSettingsfromapp.mainimportappdeffake_get_settings():returnSettings(APP_NAMETest App,DEBUGTrue)deftest_health_with_fake_settings():app.dependency_overrides[get_settings]fake_get_settingstry:clientTestClient(app)responseclient.get(/health)assertresponse.status_code200dataresponse.json()assertdata[app_name]Test Appassertdata[debug]isTruefinally:app.dependency_overrides.clear()# 必须清理否则污染其他测试断言app_name Test App通过证明没动.env也换成了假配置。TestClient(app)要在dependency_overrides设置之后创建否则覆盖不生效。技术总结把散落的配置与能力收拢成可注入、可覆盖的依赖用中间件统一处理横切逻辑用类把 LLM 客户端封装成延迟初始化、可测试的服务——这四个实践彼此呼应共同解决的是同一个工程命题让代码从能跑走向可控、可测、可维护。依赖注入是地基中间件是横切面的统一入口服务化封装消除了启动期脆弱性而覆盖测试则为前三者提供了可信保障。