删除GRPC服务中未使用RPC接口需注意哪些问题？

核心结论 #

如果已经100%确认所有客户端（包括存量和未来新接入的）都只会调用RPC1-RPC3，直接删除RPC4-RPC10是安全的，不会影响现有服务的正常运行。

关于reserved语句的说明 #

和Protocol Buffers消息字段不同，gRPC的RPC方法没有类似的reserved语法。因为gRPC是通过方法名称字符串来匹配请求的，不像消息字段依赖数字编号，所以不存在“编号冲突”的问题——只要后续新增RPC时不用已删除的旧方法名，就不会有冲突。

要警惕的风险点 #

• 遗漏客户端：如果有没排查到的客户端还在调用RPC4-RPC10，这些请求会直接返回UNIMPLEMENTED错误，导致业务异常。必须把所有客户端的调用情况都核实清楚。
• 未来复用坑：如果以后要恢复某个已删的RPC，直接用旧名称会出现兼容问题——比如旧客户端调用恢复后的方法，可能因为参数、返回值变更报错。建议后续新增类似功能时用全新的方法名。
• 冗余代码残留：删完RPC定义后，要同步清理服务端的实现逻辑、客户端SDK里自动生成的相关代码，别留冗余代码给自己添维护麻烦。

操作步骤建议 #

1. 再查一遍所有客户端的调用日志，确保完全没有RPC4-RPC10的请求记录。
2. 直接从.proto文件里删掉RPC4-RPC10的定义。
3. 重新生成服务端和客户端的gRPC代码，清理掉旧的实现逻辑。
4. 上线前在测试环境跑一遍所有现有业务流程，验证没问题。

内容的提问来源于stack exchange，提问作者nivla12345