Nameko服务启动报错“Service 'xxx' has no entrypoints”是因为类中未使用@rpc、@http或@event_handler装饰器声明入口点；需确保装饰器紧贴方法、类继承Service、模块路径正确。
nameko服务启动报错 NamekoError: Service 'xxx' has no entrypoints
这说明你定义的类里没写任何 @rpc、@http 或 @event_handler 装饰器，Nameko 找不到入口点。它不靠类名或方法名自动注册，只认显式声明的 entrypoint。
常见错误是写了普通方法但忘了加装饰器，或者把 @rpc 错贴在了类外、缩进不对、拼成了 @rpc() 却没加括号参数（其实可以不带括号，但带空括号也合法）。
- 确保每个要暴露的方法前都有
@rpc（RPC 场景）或@http（HTTP 接口） - 装饰器必须紧贴方法定义，不能隔空行，也不能缩进错误
- 类必须继承
nameko.Service（虽然不强制，但漏掉会导致上下文缺失） - 检查
nameko run后跟的模块路径是否正确，比如nameko run myservice对应的是myservice.py文件，且其中只有一个Service子类
用 @http 暴露接口时返回 JSON，但中文变乱码或字段丢失
Nameko 的 @http 默认用 json.dumps 序列化，但没设 ensure_ascii=False，也没设响应头 Content-Type: application/json; charset=utf-8，导致中文被转义、前端解析失败。
这不是 bug，是默认行为保守。你得自己控制序列化和 headers。
立即学习“Python免费学习笔记（深入）”；
- 别直接 return dict，改用
json.dumps(data, ensure_ascii=False)+ 手动设 headers - 推荐封装一个 helper 函数，统一处理编码和 content-type
- 注意
@http方法返回值是 tuple：(status, headers, body)，body 必须是 str 或 bytes - 如果用了
flask风格的jsonify，Nameko 不认——它没集成 Flask，别混用
def hello(self, request):
data = {"msg": "你好"}
return 200, {"Content-Type": "application/json; charset=utf-8"}, json.dumps(data, ensure_ascii=False)
多个服务间调用，rpc.proxy 初始化位置不对导致连接泄漏
每次请求都 new 一个 rpc.proxy 实例（比如在 HTTP handler 里写 self.rpc.other_service.method()），Nameko 会为每次调用新建 AMQP channel，短时间高并发容易耗尽 RabbitMQ 连接数，日志里出现 ChannelClosed 或连接超时。
根本原因是 rpc.proxy 应该复用，不是按需创建。Nameko 在 service 实例生命周期内自动管理底层连接，但你要让 proxy 绑定到 service 实例上。
- 在
__init__或start阶段初始化self.other_service = self.rpc.other_service，而不是每次调用时临时取 - 不要在循环或高频回调里反复访问
self.rpc.xxx—— 它不是 cheap lookup，背后有 descriptor 和 lazy channel 获取逻辑 - 确认目标服务已运行且 exchange/queue 声明成功（可用
nameko shell连上去pp list_services()验证） - RabbitMQ 默认 vhost 是
/，Nameko 默认连这里；如果改过 vhost，必须在config.yaml显式配AMQP_URI: amqp://guest:guest@localhost:5672/myvhost
本地开发时改代码要手动重启 nameko run，有没有热重载
Nameko 本身不提供热重载，nameko run 是阻塞式单进程启动，改完就得 Ctrl+C 再重跑。这不是缺陷，而是设计取舍：微服务强调隔离与可部署性，开发期便利性让位于运行时确定性。
真要省事，只能靠外部工具兜底，但要注意它们和 Nameko 的生命周期不兼容——比如 watchdog 触发重启时，旧进程可能没 clean shutdown，RabbitMQ 上的 queue 或 binding 残留，下次启动报 ResourceLocked。
- 推荐用
entr（Unix/macOS）或nodemon --exec nameko run（需装 nodemon），但加--kill-signal=SIGTERM确保优雅退出 - 更稳的做法是配合 Docker：改代码 → 构建新镜像 →
docker-compose up --force-recreate，虽然慢点，但环境一致、无残留 - 别依赖 IDE 的“rerun on change”，PyCharm 的热加载对 Nameko 无效，它拦不住 AMQP 连接释放
最常被忽略的一点：Nameko 的配置加载是启动时一次性的，config.yaml 改了不重启，服务永远读不到新配置。哪怕只是调个 log level，也得重起。
