gRPC服务必须独立进程运行，不能嵌入Django的WSGI/ASGI中；Django仅作为客户端调用，需设超时、避免阻塞，并正确管理proto导入与网络配置。
gRPC 服务不能直接跑在 Django 的 WSGI/ASGI 进程里
Django 默认用 WSGI（如 gunicorn）或 ASGI（如 daphne、uvicorn）启动，而 gRPC Python 服务依赖 grpcio 的 server.add_insecure_port() 启动独立的 HTTP/2 服务器——它和 Django 的请求生命周期完全不兼容。硬塞进 manage.py runserver 会卡死、无响应，或者抛出 RuntimeError: Event loop is closed。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 把 gRPC 服务拆成单独的 Python 进程，用
python grpc_server.py启动，监听如localhost:50051 - Django 项目只作为 gRPC 客户端，通过
grpcio的insecure_channel或secure_channel连接它 - 别试图用
django-channels或asgiref封装 gRPC server——底层协议栈不匹配，徒增复杂度 - 若需共享 Django 模型逻辑，把
models.py抽成独立包（如myproject-core），让 gRPC server 和 Django 都 pip install 它
Django 调用 gRPC 接口必须处理异步阻塞问题
gRPC Python 的默认 stub 是同步阻塞的（MyServiceStub(channel)），在 Django 视图里直接调用会拖垮整个请求线程池，尤其当后端 gRPC 服务延迟高或超时未设时，runserver 或 gunicorn 工作进程会迅速耗尽。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 始终为 channel 设置超时：
channel = grpc.insecure_channel('localhost:50051', options=[('grpc.default_authority', 'myapi.local')])，并在调用时传timeout=5 - 在视图中避免裸调用 stub 方法；改用
threading.Thread包裹（简单场景）或concurrent.futures.ThreadPoolExecutor（需复用连接） - 如果用 Django 4.1+ 且部署在
uvicorn上，可尝试async def视图 +grpc.aiostub，但注意grpc.aio不支持所有认证方式，且数据库操作仍需显式 await（Django ORM 本身不原生 async） - 错误现象示例：
ConnectionRefusedError: [Errno 111] Connection refused——不是代码错，是 gRPC server 根本没起来，先netstat -tuln | grep 50051确认端口
proto 文件生成的 Python 代码不能直接 import 到 Django app
protoc --python_out=. helloworld.proto 生成的 helloworld_pb2.py 和 helloworld_pb2_grpc.py 默认不含包声明，Python 导入系统会因路径混乱报 ModuleNotFoundError，尤其当 manage.py 在项目根目录运行而 proto 在 proto/ 子目录时。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 生成时加
--python_out=./myproject/grpc_protos，再在myproject/grpc_protos/__init__.py中补__all__ = ['helloworld_pb2', 'helloworld_pb2_grpc'] - 在 Django settings 或 app 的
apps.py中预导入，避免视图里反复写from myproject.grpc_protos import helloworld_pb2_grpc - proto 中定义的 message 字段名（如
user_id）会转成 Python 属性（user_id），但 gRPC wire 格式仍是 snake_case，不用手动映射；但若和 Django model 字段名冲突（如 model 有id，proto 有user_id），得在调用时显式赋值，别依赖自动 unpack - 别把
_pb2.py放进gitignore——它们是构建产物，应随 proto 一起提交，否则 CI 构建失败
本地开发时 DNS 和 TLS 配置最容易被忽略
生产环境常用 secure_channel 配 TLS，但本地开发用 insecure_channel 时，gRPC 默认校验 target 是否匹配证书 SAN，哪怕走 localhost 也会报 ssl.SSLError: CERTIFICATE_VERIFY_FAILED。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 开发阶段统一用
insecure_channel('localhost:50051')，别碰 TLS；上线再切secure_channel并配好 root certificates - 若必须模拟域名（如
users.api.example.com），改本地/etc/hosts，并在 channel 创建时加 option：options=[('grpc.default_authority', 'users.api.example.com')] - gRPC 日志默认关闭，调试连不上时，在启动前加：
os.environ['GRPC_VERBOSITY'] = 'DEBUG'，能看到真实解析的 IP 和连接状态 - 容器化部署时，Django 容器里访问 gRPC server 不能写
localhost:50051——得用 service 名，如users-grpc:50051，且确保 Docker network 连通
真正麻烦的从来不是写 stub 或跑 server，而是让两个进程在不同网络上下文里稳定握手；端口、host、authority、证书、线程模型——漏掉任意一环，表现都是“调不通”，但原因天差地别。
