困难一升级字段后接口集体 500数据库迁移不迁移问题描述模型新增字段如parent_allergies后本地 SQLite 库是已存在的旧表。重启后端所有宝宝接口直接 500sqlite3.OperationalError: no such column: parent_allergies排查分析create_all只建不存在的表对已有表做任何结构变更都不生效。项目中途加字段是家常便饭这意味着每次加字段都要手工删库重建——数据全丢这显然不可接受。解决步骤写一个幂等的ensure_schema()增量迁移对比 ORM 元数据与物理表结构缺列自动补充。def ensure_schema() - None: 幂等迁移对比 ORM 元数据与物理表结构缺失列自动补充。 inspector inspect(engine) existing_tables inspector.get_table_names() for table_name, table in Base.metadata.tables.items(): if table_name not in existing_tables: continue existing_cols {c[name] for c in inspector.get_columns(table_name)} for column in table.columns: if column.name in existing_cols: continue # JSON 列默认值要区分 {}dict与 []list否则响应校验会 500 default {} if isinstance(column.default.arg, dict) else [] ddl fALTER TABLE {table_name} ADD COLUMN {column.name} {_to_sql_type(column)} NOT NULL DEFAULT {default} engine.execute(text(ddl))困难二删除宝宝后冒出幽灵数据外键形同虚设问题描述测试时发现一个诡异 bug——新建一个宝宝第一次发起排敏竟然返回 400该食材已在排敏中但进度列表里明明什么都没有。排查分析逐步还原出完整链路创建宝宝 Aid3→ 发起排敏牛肉 → 删除宝宝 A返回 204 → 再创建宝宝 BSQLite 复用 id3→ 发起牛肉排敏 → 400 幽灵拦截根因是三处问题叠加所有外键都没写ondeleteCASCADESQLite 默认关闭外键约束PRAGMA foreign_keys默认 OFF即使 DDL 写了 CASCADE 也不会执行删除路由只db.delete(baby)没手动清理子数据。于是删除宝宝后方案/排敏/记录/聊天消息全部残留为孤儿数据宝宝 id 被复用后孤儿数据被误认成新宝宝的记录——幽灵数据。# ① models.py外键声明级联删除 baby_id: Mapped[int] mapped_column( ForeignKey(babies.id, ondeleteCASCADE), indexTrue, nullableFalse ) # ② database.pySQLite 每次连接强制开启外键外键是连接级设置 event.listens_for(engine, connect) def _enable_sqlite_foreign_keys(dbapi_connection, connection_record): cursor dbapi_connection.cursor() cursor.execute(PRAGMA foreign_keysON) cursor.close() # ③ delete_baby显式清理子数据对存量库立即生效 db.query(Plan).filter(Plan.baby_id baby_id).delete(synchronize_sessionFalse) db.query(AllergyProgress).filter(AllergyProgress.baby_id baby_id).delete(synchronize_sessionFalse) db.query(DailyRecord).filter(DailyRecord.baby_id baby_id).delete(synchronize_sessionFalse) db.query(DietPlan).filter(DietPlan.baby_id baby_id).delete(synchronize_sessionFalse) db.query(ChatMessage).filter(ChatMessage.baby_id baby_id).delete(synchronize_sessionFalse) db.delete(baby) db.commit()困难三PATCH 组合更新严重程度被静默清空问题描述边界测试过敏严重程度适配失败——excluded[鸡蛋]里明明有鸡蛋severity却不是预期的severe。接口返回 200但数据就是不对。排查分析这类返回 200 但数据错的 bug 最磨人。逐行读update_baby代码发现过敏数据一致性防复发逻辑有顺序缺陷# 修复前有缺陷 if allergy_severities in data and data[allergy_severities] is not None: allowed set(baby.allergies or []) # ← 用的是【旧】过敏列表 data[allergy_severities] {k: v for k, v in data[allergy_severities].items() if k in allowed} if allergies in data: allowed set(data[allergies] or []) # ← allergies 的更新在【后面】当同一次 PATCH同时传allergies[鸡蛋]和allergy_severities{鸡蛋:severe}时第一步用**旧的过敏列表空**做过滤severity 映射被清空第二步才更新 allergies。结果过敏列表更新了严重程度却丢了。解决步骤把校验基准统一为新过敏列表优先。# 修复后同请求含 allergies 时用新值否则用旧值 if allergies in data: allowed set(data[allergies] or []) else: allowed set(baby.allergies or []) if allergy_severities in data and data[allergy_severities] is not None: data[allergy_severities] {k: v for k, v in data[allergy_severities].items() if k in allowed} elif allergies in data: current_sev baby.allergy_severities or {} data[allergy_severities] {k: v for k, v in current_sev.items() if k in allowed}困难四同一天多次点击一天刷满 3 天观察期问题描述排敏设计为连续 3 天观察正常才解锁食材。但测试发现同一天内多次点击正常天数一直在涨一天就能刷满 3 天解锁——这直接违背了3 天观察的初衷。排查分析旧逻辑按每次提交都 day1累加没有区分日历天。问题本质是业务逻辑的时间粒度没想清楚天数应该是日历日维度而不是提交次数维度。解决步骤引入last_result_date与当天日期比较is_new_day rec.last_result_date ! today if is_new_day: # 新的一天昨日也为正常才累计天数异常/过敏重置观察 if payload.status normal: rec.day rec.day 1 if rec.status normal else 1 else: rec.day 1 observations.append({date: today, status: payload.status, note: payload.note}) else: # 同日重复记录更新当天结果天数不累加防止同一天多次点击刷满 3 天 observations[-1] {date: today, status: payload.status, note: payload.note}困难五DeepSeek API 一挂核心功能直接全瘫问题描述方案生成优先调 DeepSeek。个人项目没有固定预算——API Key 可能未配置、可能超时、可能报 401。一旦 LLM 挂了整个方案生成功能不可用产品直接停摆。排查分析这是 AI 应用的典型架构问题把不稳定资源当成可用资源。LLM 是外部依赖随时可能失败核心链路必须能脱离它运转。解决步骤采用规则引擎 大模型 二次校验三层架构规则层硬约束按月龄锁定食材范围、过滤过敏食材——永远不依赖 LLMLLM 层可选在约束范围内生成多样化食谱困难六中文路径下一键启动脚本解析失败问题描述一键启动脚本start-dev.ps1在中文路径d:\智慧应用\下用-File模式执行时解析失败项目起不来。排查分析Windows PowerShell 读取.ps1脚本时若文件无 UTF-8 BOM会按系统 ANSI 代码页GBK解析中文路径直接乱码。排查方向一度以为是路径转义问题绕了不少弯路。解决步骤脚本文件强制以UTF-8 BOM保存启动逻辑改为Start-Process直启不经 cmd.exe 中转避免二次转义。