最直接方法是kubectl delete，但需注意命名空间、标签选择器及传播策略；client-go批量删除须正确设置PropagationPolicy并处理分页Continue，StatefulSet删Pod需按序号和版本谨慎操作。
用 kubectl delete 命令最直接，但要注意命名空间和选择器范围
多数场景下根本不需要写 Go 代码——kubectl delete 本身就支持批量操作，且语义清晰、行为可预测。关键在控制范围，避免误删：
- 不加
-n默认只删 default 命名空间，跨命名空间必须显式指定或用--all-namespaces - 用
-l按 label 删除比用--field-selector更安全，后者容易因字段值格式（如时间戳、UID）匹配失控 -
kubectl delete pod -l app=nginx --grace-period=0 --force强制立即删除，但仅适用于已卡住的 Pod；对其他资源（如 Deployment）慎用--force，可能留下孤儿 ReplicaSet
用 client-go 调用 DeleteCollection 时，metav1.DeleteOptions 的 PropagationPolicy 必须设对
这是 Go 批量删资源最常踩的坑：调用 DeleteCollection 接口后，子资源（如 Pod）没被级联删除，不是 API 问题，而是传播策略没生效。
- 默认
PropagationPolicy是"Orphan"，即只删父资源（如 Deployment），Pod 不删 - 要真正批量清空，得显式传
&metav1.DeleteOptions{PropagationPolicy: &prop}，其中prop := metav1.DeletePropagationBackground或metav1.DeletePropagationForeground - 注意：Deployment 的
scale子资源不走 DeleteCollection，删完 Deployment 后若需清空其管理的 Pod，得单独处理或依赖控制器最终一致性
用 client-go List + Delete 循环删，Continue 字段不处理会导致漏删上千资源
当资源数量超过 API server 的 limit（默认 500），List 返回的 ResourceList.Continue 非空，但很多人忽略分页继续请求。
- 不检查
Continue，一次 List 只拿到前 500 条，后续全丢 - 正确做法是循环调用 List，每次把上一轮返回的
Continue填进下一轮ListOptions.Continue - 示例关键片段：
for continueToken != "" { list, err := client.Pods(ns).List(ctx, metav1.ListOptions{Continue: continueToken}) // ... 处理 items continueToken = list.Continue }
批量删 StatefulSet 管理的 Pod 时，podManagementPolicy 和 revision 会影响实际删除顺序
StatefulSet 的 Pod 不是无序集合，删的时候如果只按 label 列表删，可能破坏有序性或触发重建异常。
立即学习“go语言免费学习笔记（深入）”；
- 若
podManagementPolicy: OrderedReady（默认），删 Pod 必须从高序号往低序号删，否则新 Pod 可能卡在 Pending（等待前一个 Ready） - 删之前先读取 StatefulSet 的
.status.updateRevision和.status.currentRevision，确认哪些 Pod 属于旧版本，避免误删正在服务的副本 - 更稳妥的做法是先缩容
replicas: 0，等 Pod 全退完再删 StatefulSet 本身，而不是直接批量删 Pod
