执行器函数不能靠 plugin 包动态加载，因其要求主程序与插件完全相同的 go 版本、构建参数且仅支持 linux/macos，无法满足分布式调度跨平台、强隔离需求；必须采用独立子进程沙箱方案，通过进程隔离、资源限制与协议化通信实现安全可插拔。
执行器函数不能靠 plugin 包动态加载
Go 的 plugin 包在分布式调度场景下基本不可用：它要求主程序和插件使用完全相同的 Go 版本、构建参数（如 -buildmode=plugin）、且必须在 Linux/macOS 上运行——而分布式调度系统往往跨平台部署，节点可能混用不同版本 Go 或 Windows 环境。更关键的是，plugin 加载后共享主进程内存空间，无法隔离 panic、全局变量污染或资源泄漏，违背调度器对“任务失败不波及主服务”的基本要求。
常见错误现象：plugin.Open: plugin was built with a different version of package；或插件中调用 os.Exit() 直接终止整个调度进程。
- 别把
plugin当成通用插件机制，它本质是编译期耦合的动态符号链接 - 若坚持用
plugin，必须为每个执行节点预编译对应 Go 版本的插件二进制，并禁用所有非标准构建标签 - 真正需要的是“函数级可插拔”，不是“二进制级可加载”——这天然指向进程隔离方案
执行器必须走独立子进程沙箱
调度系统里的执行器函数（比如用户自定义的 RunTask）必须运行在独立进程中，这是唯一能同时满足隔离性、可观测性和资源控制的方案。goroutine 或 plugin 无法切断 http.DefaultClient、rand.Seed、log.SetOutput 等全局副作用，一个任务出错就可能让整个调度器日志混乱、HTTP 超时失效、甚至 panic 崩溃。
实操要点：
- 用
exec.CommandContext启动，传入带超时的context.Context，避免子进程卡死拖垮调度器 - 显式设置
cmd.Env，只保留最小必要环境变量（如GOPATH、PATH），清空HOME、USER等敏感项 - 用
cmd.Dir指向干净临时目录（os.MkdirTemp创建），禁止访问父路径 - 重定向
cmd.Stdin/cmd.Stdout/cmd.Stderr，避免干扰主进程日志流 - Linux 下通过
syscall.Setrlimit限制RLIMIT_AS（虚拟内存）和RLIMIT_CPU（CPU 时间）
如何让“执行器函数”看起来像可动态加载的 Go 函数
用户提交的所谓“执行器函数”，实际应作为独立可执行文件（如 task-runner）交付。调度器不解析也不反射 Go 源码，而是约定输入输出协议：子进程从 stdin 读取 JSON 任务参数，处理完成后向 stdout 写入 JSON 结果。这样既规避了编译器安全风险（如 //go:linkname 绕过），又保持语言中立——Python/JS/Rust 编写的执行器也能接入。
示例协议：
{"input": "data", "timeout_ms": 5000, "memory_mb": 128}
子进程处理完输出：
{"output": "result", "error": "", "used_time_ms": 123, "used_memory_kb": 4567}
- 不要尝试在主进程中
go run用户代码——会复用宿主模块缓存和$GOPATH - 编译用户代码时，必须指定
-o输出到临时路径，并用os.Chmod设置可执行权限 - 执行前校验二进制签名或 SHA256，防止恶意替换
沙箱策略必须按任务动态调整
不是所有任务都需要同等强度的隔离。高频计算任务可放宽网络访问但严控 CPU；数据提取任务需允许网络但禁止写文件；而用户上传的任意代码必须启用 seccomp BPF 过滤（如拦截 openat、connect 等系统调用）。静态配置一套规则会拖慢合法任务，过度宽松又留安全隐患。
关键点：
- 根据任务类型（
task_type字段）加载对应策略模板，而非统一硬编码 - Linux 下优先用
cilium/ebpf库生成并附加 BPF 程序，比libseccomp更细粒度 - 命名空间隔离（
CLONE_NEWPID+CLONE_NEWNS）必须配合 cgroup v2 使用，否则资源限制无效 - 监控子进程系统调用频率，超过阈值（如 1000 次/秒）自动升级隔离等级
真正难的不是启动一个沙箱，而是让每个任务在“足够安全”和“足够快”之间实时权衡——这需要行为采集、策略匹配、环境切换三步闭环，缺一不可。
