1. 项目概述当Django遇上无服务器架构不是妥协而是重构“Serverless Django”这个标题乍看有点矛盾——Django是典型的重量级全栈框架依赖长期运行的进程、内存中的状态、同步I/O模型而Serverless尤其是AWS Lambda强调短生命周期、事件驱动、冷启动约束、执行时间上限和内存隔离。但过去三年我亲手落地过7个生产级Serverless Django项目从内部工具到百万级用户SaaS后台结论很明确这不是把Django硬塞进Lambda的“技术杂耍”而是一次对Web应用架构本质的重新校准。核心关键词——Serverless Django、AWS Lambda、API Gateway、Django REST Framework、RDS Proxy、CloudFront缓存策略——每一个都指向一个具体的技术取舍点而非概念堆砌。它解决的不是“能不能跑”的问题而是“如何让Django在无状态、按需伸缩、按毫秒计费的环境中既保持开发体验的连贯性又榨干云原生的弹性红利”。适合三类人正在评估云迁移路径的Django老手、被运维成本压得喘不过气的初创CTO、以及想真正理解Serverless边界在哪里的架构师。我不会讲“Lambda API Gateway Serverless”的教科书定义而是直接拆解当你在settings.py里删掉DEBUGTrue在requirements.txt里加入mangum在serverless.yml里配置timeout: 30时背后每个字符都在重写Django的运行契约。2. 架构设计与核心思路拆解放弃“进程常驻”拥抱“请求即服务”2.1 为什么必须放弃传统部署模式传统Django部署Gunicorn Nginx EC2的核心假设是进程长期存活、内存可复用、连接池可维持、文件系统可写入。而Lambda彻底颠覆了这四条。我曾在一个电商后台项目中将Django直接打包进Lambda函数结果上线后每分钟触发50次冷启动平均响应延迟飙升至2.3秒——原因很简单每次调用都要重新加载整个Django应用、重建数据库连接、解析所有models、初始化中间件栈。这不是性能优化问题而是范式冲突。AWS官方文档里那句“Lambda is not for long-running processes”不是警告是判决书。所以Serverless Django的第一步不是写代码而是重构心智模型Django不再是一个“服务”而是一个“请求处理器”。它的生命周期必须与单个HTTP请求严格对齐。这意味着数据库连接不能复用Lambda容器可能被复用但连接对象如psycopg2的Connection在跨请求时极不稳定容易出现connection closed或SSL error。实测发现即使使用CONN_MAX_AGE0在高并发下仍有约12%的请求失败率。静态文件不能依赖collectstatic生成的本地路径Lambda的/tmp目录是临时的且不同调用间不共享STATIC_ROOT若指向本地路径会导致CSS/JS 404。会话存储不能用django.contrib.sessions.backends.cache或filecache后端依赖Redis/Memcached实例file后端在只读文件系统上根本不可写。必须切换到database或cached_db且数据库连接本身也要适配无状态。提示很多团队卡在第一步试图用gunicorn在Lambda里“模拟”常驻进程。我试过三次最后一次在/tmp挂载了一个FUSE文件系统来模拟/var/run结果冷启动时间从800ms涨到3.2秒且内存泄漏无法监控。放弃幻想接受现实——Django在Serverless里就是一次函数调用仅此而已。2.2 核心架构选型为什么是Mangum API Gateway v2 RDS Proxy我们最终采用的架构不是拍脑袋决定的而是踩坑后收敛出的最小可行组合Mangum这是目前最成熟的ASGI-to-Lambda适配器。它比早期的zappa更轻量比自己手写lambda_handler更健壮。关键在于它处理了ASGI生命周期的精确映射scope包含HTTP方法、路径、headers→receive接收body流→send发送response。我对比过mangum和aws-lambda-powertools的ASGI模块后者在处理大文件上传10MB时receive回调会因Lambda的5MB payload限制而截断mangum则通过分块读取临时S3存储规避了该问题。API Gateway HTTP API (v2)不是REST API。HTTP API的延迟比REST API低40%价格便宜70%且原生支持WebSocket和JWT授权。更重要的是它对Content-Type的处理更符合Django预期——REST API会强制将application/json转为application/json; charsetutf-8导致Django的request.content_type解析异常HTTP API则完全透传。我们曾用REST API上线结果所有POST表单提交都返回400查了两天才发现是这个header污染。RDS Proxy这是Serverless Django的“心脏起搏器”。没有它RDS连接数会指数级爆炸。Lambda并发100时若每个函数建立2个DB连接Django默认RDS连接池瞬间被占满新请求全部排队等待。RDS Proxy通过连接池复用将实际RDS连接数稳定在20以内。但注意Proxy不支持pgbouncer的transaction模式必须用session模式且Django的CONN_MAX_AGE必须设为0否则连接复用失效。这个组合的底层逻辑是用Mangum做协议翻译用HTTP API做流量入口用RDS Proxy做连接稳压器。三者缺一不可任何替换都会引入新的故障面。比如用ALB替代API Gateway虽然也能工作但ALB的健康检查会持续触发Lambda冷启动且无法利用HTTP API的JWT自动鉴权能力。2.3 领域边界划定哪些Django功能必须阉割或重写Serverless不是万能胶它有清晰的物理边界。我们画了一张“Django功能红绿灯图”明确标注哪些能直接用绿灯、哪些要改造黄灯、哪些必须砍掉红灯Django功能状态原因与替代方案django.contrib.admin红灯Admin依赖长连接、CSRF Token持久化、Session存储且UI大量AJAX轮询在Lambda下完全不可用。改用django-jazzmin定制轻量后台或直接对接Supabase Dashboard。django.core.files.storage.FileSystemStorage红灯/tmp空间有限512MB且不可跨调用共享。所有文件上传必须走S3预签名URL后端只存S3 Key。celery Redis Broker黄灯Celery Worker无法在Lambda常驻。改用Step Functions协调任务或用EventBridge Scheduler触发Lambda定时任务。异步邮件发送改用SES直接API调用。django.contrib.sessions.backends.cached_db绿灯只要Redis集群可用且Session Key设计合理避免热点Key完全可用。我们用django-redisTTL设为12小时。django.middleware.security.SecurityMiddleware绿灯完全兼容但SECURE_HSTS_SECONDS等设置需在CloudFront或ALB层复核避免重复生效。这个清单不是理论推演而是我们线上日志里真实报错的归因总结。比如admin红灯源于一次凌晨3点的告警OperationalError: server closed the connection unexpectedly根源是Admin的change_list页面发起12个并发AJAX请求全部撞在RDS Proxy的连接超时上。3. 核心细节解析与实操要点从settings.py到serverless.yml3.1settings.py的Serverless化改造12处必改项传统Django的settings.py像一本厚重的宪法而Serverless版本必须是一份精简的作战手册。以下是我们在生产环境验证过的12处关键修改每一处都附带原理说明和实测影响DEBUG os.getenv(DEBUG, False).lower() true必须从环境变量读取禁止硬编码。Lambda执行环境无DEBUG环境变量若不设默认值DEBUGFalse会生效但Django的runserver调试中间件仍可能残留。我们曾因此暴露了ALLOWED_HOSTS[*]的错误配置导致安全扫描告警。ALLOWED_HOSTS [your-api-id.execute-api.region.amazonaws.com, your-domain.com]API Gateway的域名是动态的必须在CI/CD中注入。硬编码[*]在生产环境是严重漏洞会绕过Django的Host头校验。DATABASES { default: { ENGINE: django.db.backends.postgresql_psycopg2, HOST: os.getenv(DB_PROXY_ENDPOINT), PORT: 5432, NAME: os.getenv(DB_NAME), USER: os.getenv(DB_USER), PASSWORD: os.getenv(DB_PASSWORD), CONN_MAX_AGE: 0 } }CONN_MAX_AGE0是铁律。RDS Proxy要求连接在每次请求后立即关闭否则连接池复用失效。实测CONN_MAX_AGE60时连接复用率从92%暴跌至35%。STATICFILES_STORAGE storages.backends.s3boto3.S3Boto3Storage所有静态文件必须托管S3。我们用django-storages配置AWS_S3_CUSTOM_DOMAIN d1234567890.cloudfront.net并开启CloudFront缓存。DEFAULT_FILE_STORAGE storages.backends.s3boto3.S3Boto3Storage同上用户上传文件直传S3后端只存Key。MEDIA_URL必须指向CloudFront域名而非S3桶名否则跨域和HTTPS问题频发。CACHES { default: { BACKEND: django_redis.cache.RedisCache, LOCATION: fredis://{os.getenv(REDIS_ENDPOINT)}:6379/0, OPTIONS: { CLIENT_CLASS: django_redis.client.DefaultClient, CONNECTION_POOL_KWARGS: {max_connections: 20} } } }Redis连接池大小必须显式限制。Lambda并发100时若每个函数创建独立连接池Redis连接数瞬间突破1000。max_connections20经压测验证可支撑并发500。LOGGING { version: 1, disable_existing_loggers: False, handlers: { console: { class: logging.StreamHandler, formatter: verbose } }, formatters: { verbose: { format: %(asctime)s %(name)-12s %(levelname)-8s %(message)s } }, loggers: { django: { handlers: [console], level: INFO } } }Lambda日志必须输出到stdoutCloudWatch Logs才能捕获。禁用FileHandler否则报错OSError: [Errno 30] Read-only file system。SECRET_KEY os.getenv(DJANGO_SECRET_KEY)绝对禁止硬编码。我们用AWS Secrets Manager存储Lambda执行角色有权限读取启动时注入环境变量。SECURE_SSL_REDIRECT True强制HTTPS。API Gateway已终止SSL但Lambda内网通信是HTTP所以此设置必须为True由CloudFront或ALB处理重定向。SESSION_ENGINE django.contrib.sessions.backends.cached_dbSession存储必须是cached_db兼顾速度与持久性。纯cache在Redis故障时会丢失所有Session。USE_TZ TrueServerless环境时区不可靠必须启用时区支持。datetime.now()在Lambda里可能返回UTC或本地时间取决于底层AMIUSE_TZTrue确保所有时间操作基于UTC。AWS_S3_OBJECT_PARAMETERS {CacheControl: max-age86400}S3对象强制添加Cache-Control头配合CloudFront缓存策略避免重复拉取静态资源。注意这些修改不是“开关式”配置而是相互耦合的系统工程。比如CONN_MAX_AGE0和RDS Proxy必须同时启用否则连接池失效STATICFILES_STORAGE和AWS_S3_OBJECT_PARAMETERS必须配套否则CloudFront无法识别缓存头。漏掉任意一项都可能导致线上500错误。3.2serverless.yml配置详解不只是部署脚本更是架构说明书serverless.yml是Serverless Django的“宪法性文件”它定义了函数、事件、权限、环境的完整契约。以下是我们的生产级配置逐行解释其设计意图service: my-django-app provider: name: aws runtime: python3.11 region: us-east-1 stage: ${opt:stage, dev} memorySize: 1024 timeout: 30 environment: DJANGO_SETTINGS_MODULE: myproject.settings.serverless DEBUG: ${env:DEBUG, False} DB_PROXY_ENDPOINT: ${ssm:/myapp/db/proxy/endpoint~true} REDIS_ENDPOINT: ${ssm:/myapp/redis/endpoint~true} DJANGO_SECRET_KEY: ${ssm:/myapp/django/secret_key~true} iamRoleStatements: - Effect: Allow Action: - ssm:GetParameter - secretsmanager:GetSecretValue Resource: * - Effect: Allow Action: - s3:GetObject - s3:PutObject Resource: arn:aws:s3:::myapp-static-bucket/* - Effect: Allow Action: - rds-db:connect Resource: arn:aws:rds-db:us-east-1:123456789012:dbuser:cluster-abc123/myappuser functions: api: handler: myproject.asgi.handler events: - httpApi: path: /{proxy} method: ANY package: include: - myproject/** - requirements.txt exclude: - **/__pycache__/** - **/*.pyc - .git/**runtime: python3.11Python 3.11比3.9快10-15%冷启动时间减少约200ms。Lambda对3.11的优化已非常成熟无需担心兼容性。memorySize: 1024这不是随便写的。Django应用冷启动时内存占用峰值约750MB含ASGI框架、Django core、ORM。1024MB是经过/tmp空间预留256MB后的安全值。设为512MB时import django阶段就OOM。timeout: 30API Gateway HTTP API最大超时30秒Lambda必须匹配。但注意Django的TIMEOUT设置如数据库查询超时必须小于30秒我们统一设为25秒留5秒给网络传输和Lambda调度。environment中的SSM参数所有敏感配置DB endpoint、Redis endpoint、Secret Key都从SSM Parameter Store读取而非硬编码在YAML里。~true表示解密/myapp/db/proxy/endpoint是层级化路径便于权限管理。iamRoleStatements权限最小化原则。rds-db:connect是RDS Proxy连接必需的而非rds:ConnectS3权限精确到myapp-static-bucket/*而非整个S3。httpApi: path: /{proxy}{proxy}是通配符将所有路径/api/users/,/static/css/app.css都路由到同一函数。Django的URL Router负责后续分发避免在API Gateway层配置冗余路由。package: include/exclude只打包必要文件。排除.git和__pycache__可减少部署包体积30%冷启动更快。我们实测部署包从120MB减到85MB后冷启动P95延迟从1.8s降至1.2s。这个配置文件的价值远超部署脚本。它是团队对Serverless约束的集体认知结晶每一次sls deploy都是对架构契约的确认。4. 实操过程与核心环节实现从本地开发到灰度发布4.1 本地开发环境如何让manage.py在Serverless模式下工作最大的误区是认为“Serverless 不能本地开发”。恰恰相反本地开发体验必须比传统部署更好。我们的方案是用Docker模拟Lambda运行时用LocalStack模拟AWS服务。首先创建docker-compose.ymlversion: 3.8 services: django-dev: build: . ports: - 8000:8000 environment: - DJANGO_SETTINGS_MODULEmyproject.settings.local - DEBUGTrue - DB_HOSTlocalhost - DB_PORT5432 - REDIS_HOSTredis depends_on: - db - redis db: image: postgres:14 environment: - POSTGRES_DBmyapp - POSTGRES_USERmyappuser - POSTGRES_PASSWORDmyapppass redis: image: redis:7-alpine关键点在于myproject/settings/local.pyfrom .base import * DEBUG True ALLOWED_HOSTS [localhost, 127.0.0.1] # 数据库指向本地PostgreSQL DATABASES { default: { ENGINE: django.db.backends.postgresql_psycopg2, HOST: os.getenv(DB_HOST, localhost), PORT: os.getenv(DB_PORT, 5432), NAME: myapp, USER: myappuser, PASSWORD: myapppass, CONN_MAX_AGE: 0, } } # Redis指向本地 CACHES { default: { BACKEND: django_redis.cache.RedisCache, LOCATION: redis://redis:6379/0, } } # 静态文件仍用本地 STATICFILES_STORAGE django.contrib.staticfiles.storage.StaticFilesStorage这样docker-compose up后http://localhost:8000就能访问一个100% Serverless兼容的Django环境。所有manage.py命令makemigrations,shell,test都可正常运行。我们甚至用pytest跑单元测试覆盖率要求≥85%因为Serverless环境下任何未覆盖的分支都可能在冷启动时暴露。实操心得本地开发时务必在settings/local.py里加一行print(Using local settings)并在settings/serverless.py里加print(Using serverless settings)。无数次我们因为忘记切换settings module导致本地调试时用着生产数据库配置差点删库。4.2 静态文件与媒体文件的Serverless流水线传统Django的collectstatic在Serverless里是反模式。我们的CI/CD流水线GitHub Actions做了三件事构建阶段pip install -r requirements.txt --target ./package然后cp -r myproject ./package最后zip -r deploy.zip -j ./package/*。-j参数去除路径层级确保Lambda解压后是平铺结构。静态文件上传aws s3 sync --delete ./staticfiles/ s3://myapp-static-bucket/ --cache-control max-age31536000,public。--delete确保旧文件被清理--cache-control设置一年缓存CloudFront会尊重此头。CloudFront缓存策略创建自定义缓存策略关键配置Cache key and origin requests→Cache policy→Managed-CachingOptimizedQuery stringsInclude all (Django的?v123版本号需要)HeadersWhitelistOrigin,Accept-EncodingCookiesNone (Django Session ID已由Cookie策略处理)这套流水线的关键洞察是静态文件的部署与应用代码的部署必须解耦。Lambda函数更新时静态文件不应重新上传静态文件更新时Lambda函数也不应重启。我们用aws cloudfront create-invalidation --distribution-id E1234567890 --paths /*实现秒级刷新。4.3 数据库迁移如何在无服务器环境中安全执行migratepython manage.py migrate在Serverless里是个地雷。Lambda函数是无状态的但迁移是状态变更操作。我们的方案是将迁移作为独立的、一次性执行的Lambda函数。创建migrate_handler.pyimport os import django from django.core.management import execute_from_command_line os.environ.setdefault(DJANGO_SETTINGS_MODULE, myproject.settings.serverless) django.setup() def lambda_handler(event, context): # 检查是否已执行过此迁移ID用DynamoDB记录 import boto3 dynamodb boto3.resource(dynamodb) table dynamodb.Table(migration-log) response table.get_item(Key{migration_id: event[migration_id]}) if Item in response: return {status: skipped, reason: already executed} # 执行迁移 execute_from_command_line([manage.py, migrate, --noinput]) # 记录执行日志 table.put_item(Item{ migration_id: event[migration_id], executed_at: str(datetime.now()), lambda_request_id: context.aws_request_id }) return {status: success}部署时用sls invoke -f migrate --data {migration_id:20231001_add_user_profile}手动触发。每次发布新版本前CI/CD自动触发此函数并传入Git Commit Hash作为migration_id。这样无论部署多少次迁移只执行一次且可审计。注意此函数必须有rds-db:connect权限且timeout设为300秒5分钟因为大型迁移可能耗时较长。我们曾有一次迁移耗时217秒若timeout设为60秒函数会中断数据库锁住。4.4 灰度发布与回滚用API Gateway的Stage和权重控制Serverless Django的发布不是“一刀切”而是渐进式。我们利用API Gateway的Stage和Routing权重创建两个Stageprod主流量和canary灰度流量在prodStage绑定api-prod函数在canaryStage绑定api-canary函数新版本配置HTTP API的Route将10%流量导向canary90%导向prod监控CloudWatch指标5XXErrorRate、IntegrationLatency、Throttles若canary的5XXErrorRate 0.5%立即在API Gateway控制台将权重调回0%回滚更简单只需将canaryStage的函数别名指向旧版本ARN无需重新部署。整个过程在30秒内完成用户无感知。我们用Terraform管理这些Stage配置确保基础设施即代码。5. 常见问题与排查技巧实录那些没写在文档里的坑5.1 冷启动延迟从2.1秒到320毫秒的优化路径冷启动是Serverless Django的头号敌人。我们记录了某次上线的冷启动P95延迟变化优化措施P95冷启动延迟说明初始状态默认配置2140msPython 3.9, 512MB内存, 无预热升级Python 3.111820ms解释器启动更快内存升至1024MB1450ms更多CPU份额ASGI加载加速启用Lambda预置并发2个890ms预热容器常驻但成本增加迁移至ARM64架构Graviton2620msARM64比x86快约35%且价格便宜20%代码层优化懒加载、减少import320ms关键将import django移到handler内from django.conf import settings提前最终方案是ARM64 1024MB 预置并发2。预置并发不是越多越好我们测算过预置1个并发成本增加$0.02/小时预置5个并发成本$0.10/小时但P95延迟只再降40ms。性价比拐点在2个。排查技巧在Lambda函数开头加import time; start_time time.time()结尾加print(fInit time: {time.time() - start_time})。这个“init time”就是冷启动耗时与CloudWatch的InitDuration指标一致。不要相信第三方监控工具的“冷启动”统计它们往往不准。5.2 数据库连接池耗尽RDS Proxy的隐藏陷阱RDS Proxy看似完美但它有两个致命陷阱Transaction模式不支持Django的atomic装饰器默认开启事务RDS Proxy在transaction模式下会为每个事务创建新连接导致连接池爆炸。解决方案在settings.py中强制ATOMIC_REQUESTS False并在需要事务的地方显式用with transaction.atomic():。连接泄漏检测缺失RDS Proxy不会主动回收“僵尸连接”。如果Django代码中有try/except捕获了数据库异常但未关闭连接连接会一直挂在Proxy上。我们用CloudWatch指标DatabaseConnections监控当DatabaseConnections 100且CPUUtilization 10%时触发告警人工介入rds-proxy重启。实操心得在Django的DATABASES配置里加一行OPTIONS: {keepalives: 1, keepalives_idle: 30, keepalives_interval: 10, keepalives_count: 5}。这是psycopg2的TCP Keepalive参数能主动探测并清理死连接将连接泄漏率从15%降至0.3%。5.3 CORS错误API Gateway与Django的双重防护CORS错误是Serverless Django最常被问的问题。根源在于API Gateway和Django都试图处理CORS结果互相打架。Django的django-cors-headers中间件会添加Access-Control-Allow-Origin等头API Gateway的CORS设置也会添加同样的头浏览器收到重复头直接拒绝响应解决方案只让API Gateway管CORSDjango中间件彻底禁用。在settings.py中# 禁用Django的CORS中间件 MIDDLEWARE [ # ... 其他中间件 # corsheaders.middleware.CorsMiddleware, # 注释掉这一行 # ... ] # 但保留CORS_ALLOWED_ORIGINS用于Django内部逻辑如CSRF CORS_ALLOWED_ORIGINS [ https://myapp.com, https://staging.myapp.com, ]然后在API Gateway HTTP API中配置CORSAccess-Control-Allow-Origin:https://myapp.comAccess-Control-Allow-Methods:GET,POST,PUT,DELETE,OPTIONSAccess-Control-Allow-Headers:Content-Type,X-CSRFToken,AuthorizationAccess-Control-Expose-Headers:X-Total-Count,X-Page这样CORS头由API Gateway统一注入Django只负责业务逻辑职责清晰。5.4 日志与监控如何从CloudWatch里挖出真问题Serverless的日志是碎片化的。一个HTTP请求可能跨越API Gateway、Lambda、RDS Proxy、RDS四个服务日志分散在四个CloudWatch Log Group里。我们的排查流程是从API Gateway日志入手搜索/api/users/路径找到requestId如a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8用requestId过滤Lambda日志filterLogEvents --log-group-name /aws/lambda/my-django-app-api --filter-pattern a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8若Lambda日志显示DB connection failed用requestId查RDS Proxy日志filterLogEvents --log-group-name /aws/rds/proxy/my-proxy --filter-pattern a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8最后查RDS日志filterLogEvents --log-group-name /aws/rds/cluster/my-cluster/error --filter-pattern a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8我们写了一个Python脚本correlate_logs.py自动完成这四步输入requestId输出整合日志。这个脚本成了SRE团队的标配工具。常见问题速查表现象可能原因排查命令502 Bad GatewayAPI Gateway未收到Lambda响应aws logs filter-log-events --log-group-name /aws/apigateway/my-api --filter-pattern 502504 Gateway TimeoutLambda执行超时或API Gateway超时设置过小aws logs filter-log-events --log-group-name /aws/lambda/my-django-app-api --filter-pattern Task timed outConnection refusedRDS Proxy endpoint配置错误或安全组未放行aws rds describe-db-proxies --db-proxy-name my-proxyNo module named mangumrequirements.txt未正确打包或package.include遗漏aws lambda get-function-code --function-name my-django-app-api下载zip检查5.5 安全加固Serverless Django的最小攻击面Serverless不等于安全。我们加固了五个层面Lambda层执行角色权限最小化禁用*:*只授予rds-db:connect、s3:GetObject等具体动作。API Gateway层启用WAF规则集包括AWS-AWSManagedRulesCommonRuleSet防SQLi/XSS和AWS-AWSManagedRulesKnownBadInputsRuleSet防恶意payload。Django层SECURE_BROWSER_XSS_FILTER TrueSECURE_CONTENT_TYPE_NOSNIFF TrueX_FRAME_OPTIONS DENY。RDS层启用加密KMS禁用公有访问VPC安全组只允许RDS Proxy IP段。S3层静态桶策略禁止s3:GetObject以外的所有动作且Condition中aws:SourceIp限定为CloudFront IP段。最关键的加固是所有Django管理命令createsuperuser,changepassword都禁用。生产环境不允许交互式命令。管理员账户通过Django Admin API受JWT保护或直接SQL创建。我在实际操作中发现最有效的安全实践不是堆砌工具而是把安全检查变成CI/CD的门禁。我们在GitHub Actions里加了一步pip install bandit bandit -r myproject/扫描所有Python文件的硬编码密码、危险函数调用。任何bandit告警CI直接失败。这个习惯让我们在三年内零安全事件。