Python后端性能优化往往不是从改代码开始的，而是先定位到真正的瓶颈。多数项目的性能问题集中在数据库查询、序列化开销、同步阻塞和重复计算上。与其盲目加缓存或换框架，不如先用cProfile、py-spy或Django Debug Toolbar这类工具抓出耗时最高的函数和SQL。比如一个列表接口慢，先看是ORM发出了几十条查询，还是单条SQL本身扫描了几百万行，又或者是JSON序列化大对象占用了CPU。定位准确后，优化手段才有意义。
数据库查询优化是回报率最高的环节
ORM用起来方便，但隐藏的N+1查询问题几乎每个项目都会遇到。比如查询文章列表时，循环里再去查作者信息，就会产生1次查文章加N次查作者的SQL。Django里用select_related和prefetch_related，SQLAlchemy里用joinedload和selectinload，可以把查询次数从几十次降到一两次。另一个常见问题是只取需要的字段，不要每次都用SELECT *，尤其是表里有大文本字段时。使用only、defer或query时指定列，能明显减少网络传输和内存占用。
索引不是越多越好，但关键查询字段必须有。分析慢查询日志，找到WHERE、ORDER BY、JOIN条件里频繁出现的列，建立联合索引。注意联合索引的最左前缀原则，比如索引(a, b, c)能加速a、a+b、a+b+c的查询，但单独查b或c用不上。对于分页深翻的场景，LIMIT 100000, 20这种写法会扫描并丢弃前十万行，可以改用基于游标的分页，例如记住上一页最后一条记录的id，用WHERE id > last_id ORDER BY id LIMIT 20，性能提升非常明显。
缓存策略要分层设计
不要一上来就把所有接口都加缓存，先区分数据的热度和一致性要求。对于读多写少、实时性要求不高的数据，比如分类列表、配置项、热门文章，可以用Redis做进程外缓存。缓存键要规范，包含版本号或数据指纹，避免更新数据后旧缓存一直不失效。设置合理的过期时间，并加上随机抖动，防止缓存雪崩。对于用户维度的数据，比如个人信息、权限，可以用本地内存缓存或请求级缓存，减少跨进程访问开销。
缓存穿透、击穿和雪崩是三个必须处理的问题。穿透是指查询一个不存在的数据，缓存和数据库都没有，导致每次请求都打到数据库。可以用布隆过滤器或者把空结果也缓存几分钟。击穿是指某个热点key过期瞬间，大量请求同时打到数据库。可以加互斥锁，只让一个请求去加载数据，其他请求等待。雪崩是指大量key同时过期，数据库压力骤增。给过期时间加随机值就能有效缓解。
异步与并发处理
Python的GIL让多线程在CPU密集型任务上表现不佳，但IO密集型任务仍然能从多线程或协程中获益。FastAPI、Sanic、Tornado这些异步框架适合处理高并发IO场景，比如调用第三方API、读写文件、数据库查询。异步代码的关键是不要在async函数里调用阻塞操作，比如requests库、同步的ORM查询。用httpx的异步客户端、SQLAlchemy的async版本，或者把阻塞操作丢到线程池里执行。
对于耗时任务，比如发送邮件、生成报表、图片处理，不要放在请求主流程里同步执行。用Celery、RQ或Dramatiq这类任务队列把工作异步化。任务设计要幂等，因为重试可能导致重复执行。队列消费速度要监控，积压过多说明消费者不够或者任务本身太慢。对于需要实时推送的场景，WebSocket比轮询更高效，但要注意连接管理和消息广播的复杂度。
代码层面的性能细节
Python里一些看似微小的写法差异，在高频调用下会放大成明显瓶颈。字符串拼接在循环里用join而不是+，因为+每次都会创建新字符串。列表推导式通常比显式for循环快，但不要在推导式里做太复杂的逻辑。生成器适合处理大数据流，避免一次性加载全部数据到内存。对于频繁调用的函数，可以用functools.lru_cache做结果缓存，但要注意参数必须可哈希，且函数没有副作用。
序列化和反序列化也是常见开销点。JSON处理大响应时，用ujson或orjson替代标准库json，速度能提升数倍。对于内部服务通信，可以考虑MessagePack或Protobuf，体积更小、解析更快。如果接口返回的字段很多但客户端只用其中几个，提供字段筛选参数，减少无效数据传输。响应体压缩用gzip或br，在Nginx层开启即可，对文本类数据压缩率很高。
安全防护从输入开始
所有外部输入都是不可信的，包括URL参数、请求体、请求头、Cookie，甚至第三方API的返回数据。SQL注入是最经典也最不该出现的问题，使用ORM或参数化查询就能基本杜绝。不要拼接SQL字符串，哪怕是为了动态排序或过滤。如果必须拼接，对字段名做白名单校验，对值做参数绑定。命令注入同样危险，避免使用os.system或subprocess时直接拼接用户输入，用参数列表形式传递。
XSS攻击在服务端渲染模板时尤其要小心。所有输出到HTML的内容都要做转义，Jinja2、Django模板默认会转义，但用safe过滤器或mark_safe时要确认内容确实安全。对于用户提交的富文本，用白名单过滤标签和属性，比如bleach库。CSP策略能有效降低XSS危害，限制脚本来源、禁止内联脚本。即使有漏洞，攻击者也难以执行恶意代码。
CSRF防护在表单提交场景中必须启用。Django自带CSRF中间件，Flask可以用Flask-WTF。对于前后端分离的项目，如果使用Token认证，确保Token不存储在Cookie中，而是放在Authorization头里，这样浏览器不会自动携带，天然免疫CSRF。如果使用Cookie存储Session，设置SameSite=Lax或Strict属性，也能阻断跨站请求。
认证与授权不能只做表面
密码存储必须用强哈希算法，bcrypt、argon2或PBKDF2都可以，绝对不能MD5或SHA1直接存。加盐是基本要求，现代算法已经内置了盐。登录接口要加频率限制，防止暴力破解。失败次数达到阈值后锁定账户或要求验证码。JWT的使用要注意过期时间、签名算法和密钥管理。不要把敏感信息放在JWT的payload里，因为payload只是base64编码，任何人都能解码查看。
权限控制要覆盖到每一个接口，不能只在前端隐藏按钮。后端必须校验当前用户是否有权访问该资源。对象级权限容易被忽视，比如用户A通过修改URL中的id访问用户B的数据。在查询时加上用户维度的过滤条件，或者用权限框架做统一校验。对于管理后台，限制访问IP、启用二次验证、记录操作日志都是必要的。
依赖与配置安全
第三方库是安全风险的重灾区。定期用pip-audit、safety或GitHub的Dependabot检查依赖漏洞，及时升级。不要使用来源不明的包，安装前确认包名是否正确，防止typosquatting攻击。生产环境的配置文件不能提交到代码仓库，密钥、数据库密码、API密钥用环境变量或密钥管理服务注入。DEBUG模式在生产环境必须关闭，否则错误页面会泄露代码路径、配置信息甚至数据库结构。
HTTP安全头是性价比很高的防护手段。设置X-Content-Type-Options: nosniff防止MIME类型嗅探，X-Frame-Options: DENY防止点击劫持，Strict-Transport-Security强制HTTPS。对于API服务，限制请求体大小，防止恶意大包耗尽内存。设置合理的超时时间，避免慢请求占满连接池。在Nginx或网关层做限流，按IP、接口维度控制QPS，能挡住大部分恶意爬虫和扫描器。
日志与监控是最后防线
安全事件发生后，没有日志就无法溯源。记录关键操作日志，包括登录、注册、修改密码、删除数据、支付等。日志中不要记录密码、Token、身份证号等敏感信息。结构化日志便于检索和分析，用JSON格式输出，配合ELK或Loki做集中管理。监控接口响应时间、错误率、数据库连接数、队列积压量，异常波动往往意味着性能问题或攻击行为。
性能优化和安全防护不是一次性工作，而是贯穿开发、测试、上线的持续过程。每次上线新功能后，重新跑一遍性能基准测试和安全扫描。把常见的优化手段沉淀成团队规范，比如ORM查询规范、缓存使用规范、输入校验规范。代码审查时重点关注SQL拼接、权限校验、异常处理这些高风险点。只有把这些实践变成习惯，后端服务才能在流量增长和攻击面前保持稳定。
