服务隔离需通过独立进程或容器实现，而非go语言特性；资源隔离依赖os机制如cgroups、docker限制；goroutine泄漏是软性隔离失效主因；配置应驱动超时、连接数等隔离参数，避免硬编码。
服务隔离：用独立进程或容器边界切分依赖
Go 本身不提供内置的“服务隔离”机制，service isolation 是架构层面的设计选择，不是语言特性。真正起作用的是进程边界、网络边界和部署单元。你在单个 main 进程里启动多个 HTTP handler 或 goroutine，并不构成服务隔离——它们共享内存、panic 栈、日志上下文、甚至 http.DefaultServeMux；一个 handler 崩溃可能拖垮整个进程。
可行做法是：把不同职责的服务拆成独立可执行文件（如 auth-svc、order-svc），各自监听不同端口，通过 HTTP/gRPC 调用。Kubernetes 中每个服务对应一个 Deployment + Service，这才是实际生效的隔离层。
- 避免在单个二进制中用
goroutine模拟多服务——它掩盖了错误传播、超时传递、资源争抢等问题 - 跨服务调用必须显式加
context.WithTimeout，否则下游卡住会拖死上游 - 健康检查端点（如
/healthz）要只检查本服务依赖（比如只连自己的 DB），不能探测其他服务
资源隔离：靠 OS 机制，Go 只负责配合
Go 程序内部无法真正“隔离 CPU 或内存”，runtime.GOMAXPROCS 控制的是 P 的数量，不是 CPU 核心绑定；debug.SetMemoryLimit（Go 1.19+）仅触发 GC 压力提示，不阻止 OOM。真正的资源隔离靠外部：cgroups（Linux）、Docker --memory/--cpus、K8s resources.limits。
Go 能做的是不越界、可观察、易中断：
