轻量依赖打包报错主因是路径结构错误或C扩展不兼容：-t指定目录后若压缩整个文件夹，解压多出一层导致导入失败；纯Python包如ujson、cryptography等含平台相关二进制，须用Linux容器构建确保兼容。
轻量依赖（如 requests、pydantic、python-dateutil）在 Serverless 中基本能直接打包上传，无需额外架构改造——但前提是路径结构正确、无隐式 C 扩展、不跨平台编译。
为什么 pip install -r requirements.txt -t ./package 有时仍报错？
常见错误不是“没装”，而是“装对了但找不到”。Serverless 运行时（如 AWS Lambda、阿里云 FC）只在 sys.path 的固定位置查找模块：默认是函数根目录，以及 /opt/python（当使用 Layer 时）。如果你用 -t ./package 输出到 ./package/requests/，但部署时把整个 package/ 文件夹压缩上传，解压后实际路径变成 package/requests/ —— 解释器就不会自动扫描子目录。
- 正确做法：确保
pip install -r requirements.txt -t .（即安装到当前目录），再把所有*.py和顶层包文件夹（如requests/、pydantic/）与你的handler.py放在同一级目录下 - 错误示范：
zip -r function.zip package/→ 解压后路径多了一层package/，导致导入失败 - 验证方式：本地解压 zip 包，执行
python -c "import requests; print(requests.__file__)"，路径应指向 zip 内的requests/__init__.py，而非系统 site-packages
哪些“轻量”依赖其实暗藏风险？
表面纯 Python，实则带 C 扩展或平台绑定的包，在 macOS 或 Windows 上直接 pip 安装后上传，大概率在 Linux 运行时崩溃。典型例子：
-
ujson：C 实现的 JSON 加速库，本地编译的.so文件无法在 Lambda 的 Amazon Linux 2 上加载 -
cryptography：依赖 OpenSSL 和 rust 编译，必须用容器构建（如docker run --rm -v $(pwd):/var/task public.ecr.aws/lambda/python:3.10 pip install cryptography -t .） -
orjson：Rust 编译产物，同样不兼容跨平台 pip
判断方法：运行 python -c "import xxx; print(getattr(xxx, '__file__', 'no __file__'))"，如果输出路径含 .so 或 .dylib，就需警惕。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
立即学习“Python免费学习笔记（深入）”；
Serverless Framework 下如何安全打包？
用 serverless-python-requirements 插件时，别只开 slim: true，还要关掉本地 pip 缓存干扰：
- 在
serverless.yml的custom.pythonRequirements下显式设置：useDownloadCache: false和useStaticCache: false - 强制每次从干净环境重装，避免复用本地 wheel 导致架构错配
- 加上
dockerizePip: non-linux（而非true），这样 macOS/Windows 用户也能触发容器构建，保证二进制兼容 - 检查生成的
.serverless/xxx.zip：用unzip -l确认requests/直接在 zip 根下，而非嵌套在package/requests/
真正容易被忽略的点：即使依赖本身轻量，只要它间接依赖了 numpy 或 scipy（比如某个统计工具包），整个树就会膨胀。上线前务必跑一次 pipdeptree --reverse --packages requests，看清依赖链末端有没有重型模块。
