文件在模型服务化中的各个状态IncomingFile➡FileItem；项目异常抛出体系；环境变量url与普通常量url区别；

1.文件在模型服务化中的各个状态IncomingFile➡FileItem；

IncomingFile
(HTTP 层 / 短生命)
      │  read()
      ▼
FileItem
(业务层 / 稳定生命)
      │
      ├── 推理
      ├── 缓存
      ├── 写盘
      ├── 进队列

IncomingFile# IncomingFile
FileItem # 内存态
StoredFile # 已落盘 / 有 path
CachedFile # 有 hash / cache_key

IncomingFile与FileItem的信任边界不同：
（1）IncomingFile：HTTP / 框架层模型
（2）FileItem：业务 / 领域层模型

2.模型服务化项目异常抛出体系设计
👉在模型服务化的整体架构中，各层异常体系设计：

异常类型	它在“描述什么”	应该产生在哪一层	router 的角色
InvalidRequestError	请求本身不合法	API / Router 层	直接抛 / 转 HTTP 400
UnsupportedOperationError	业务上不支持	Service / Domain 层	捕获并呈现
ExternalServiceError	下游依赖失败	Adapter / Infra 层	只看结果，不关心细节

3.环境变量url与普通常量url区别；
👉今天让copilot写系统url管理时发现：

PADDLE_EXTRACT_URL = os.environ.get(
    "PADDLE_EXTRACT_URL",
    "http://localhost:8003/paddle/pp-structurev3/predict",
)

👉copilot优先从运行环境读配置："PADDLE_EXTRACT_URL"
👉如果没配，就用一个安全的默认值："http://localhost:8003/paddle/pp-structurev3/predict"

项目	环境变量	普通常量
生效时机	运行时	编译 / 启动前
改变方式	改环境，不改代码	改代码
是否影响镜像	不影响	影响
是否影响测试	可隔离	易污染

❌ 1. 代码和环境强耦合
本地 → staging → 生产；每换环境就要改代码；
❌ 2. Docker / K8s 极不友好
镜像一旦构建；URL 被写死；
❌ 3. 无法做灰度 / 多实例
同一服务连不同后端直接卡死；