.NET Core 3.1调用Shell脚本启动Node.js应用异常排查咨询

你当前通过C#启动子进程调用Shell脚本、再触发Node应用的方案，完全适配Azure消息队列消费者触发独立Node任务的场景。代码无报错但无预期输出，是以下明确的实现问题导致，和方案本身无关：

• 错误流未捕获：你仅开启了标准输出重定向，Shell脚本报错、Node运行时错误全部走标准错误流，未重定向读取的情况下所有错误会被静默吞掉，完全看不到异常提示。
• 流读取死锁：你同步调用StandardOutput.ReadToEnd()后再执行WaitForExit()，如果脚本输出内容填满流缓冲区，或是错误流有内容写入但无人读取，子进程会被阻塞等待缓冲区释放，最终卡死无响应。
• 占位符未替换：参数中写的{url}、{OUTPUT_PATH}等内容只是字面量标记，没有替换为实际业务值，脚本拿到无效参数自然无法生成预期文件。
• 工作目录缺失：你未显式设置子进程工作目录，子进程默认工作目录是.NET应用的执行目录，如果脚本内用相对路径寻址Node入口、配置文件或输出目录，会直接出现路径找不到的问题。
• 本地Windows测试环境兼容问题：Windows默认不会将bash加入系统PATH，如果你没有安装WSL/Git Bash/Cygwin这类提供bash运行环境的组件，Process.Start("bash")会直接启动失败，且因为错误被吞无法感知。
• 冗余代码风险：你定义了myBatchFile变量存储脚本路径但全程未使用，Arguments中硬编码重复的脚本路径，很容易出现两边路径不一致的低级错误。

// 提前替换所有占位符为实际业务取值
var scriptPath = @"/app/spiderease/run.sh"; // 统一使用绝对路径，本地调试可按运行环境切换
var args = $"\"{scriptPath}\" CA--STATCAN--REG--ADMIN-DATA \"{actualUrl}\" \"{outputFullPath}\" \"{spiderEaseHome}\" \"{spiderTemplateHome}\" \"{taskType}\"";

var processStartInfo = new ProcessStartInfo
{
    FileName = "bash",
    Arguments = args,
    UseShellExecute = false,
    RedirectStandardOutput = true,
    RedirectStandardError = true, // 必须开启，否则拿不到报错信息
    WorkingDirectory = Path.GetDirectoryName(scriptPath)!, // 显式指定工作目录，避免相对路径失效
    CreateNoWindow = true
};

using var process = Process.Start(processStartInfo) ?? throw new InvalidOperationException("子进程启动失败");
// 异步并行读取两个流，避免缓冲区满导致死锁
var outputReadTask = process.StandardOutput.ReadToEndAsync();
var errorReadTask = process.StandardError.ReadToEndAsync();

process.WaitForExit();
var stdOut = await outputReadTask;
var stdErr = await errorReadTask;

// 必须校验退出码，非0值均代表执行失败
if (process.ExitCode != 0)
{
    throw new InvalidOperationException($"Node任务执行失败，退出码：{process.ExitCode}，标准输出：{stdOut}，错误信息：{stdErr}");
}

// 后续业务逻辑可直接使用stdOut中的脚本输出内容

根据你的Node应用特性，可以选择更适配的实现方式：

• 如果Node应用逻辑轻量、第三方依赖少，可直接使用.NET内嵌JS运行时（如Jint、ClearScript）在当前进程内执行JS逻辑，省掉跨进程调用开销，部署和调试成本更低。
• 如果Node应用是常驻服务类程序，不要每次消费消息就冷启动一次Node进程，可将Node应用包装为HTTP/gRPC服务，.NET消费者通过接口调用触发任务，完全消除冷启动开销，也方便对Node服务做独立扩缩容、监控配置。
• 如果Node应用是单次执行的短周期任务，当前修复后的跨进程调用方案完全够用，不需要额外改造。

• 基础镜像选择：不要使用纯.NET Core 3.1 Runtime镜像，需要基于官方.NET 3.1运行时镜像额外安装对应版本的Node.js运行时，否则脚本调用node命令时会提示找不到程序。
• 路径与权限配置：所有脚本、Node应用、输出目录全部使用Linux风格绝对路径，不要带Windows盘符；Dockerfile中需要给run.sh脚本和Node入口文件添加可执行权限，例：RUN chmod +x /app/spiderease/run.sh /app/spiderease/index.js。
• 环境变量配置：脚本依赖的SPIDER_EASE_HOME这类环境变量，不要依赖本地用户的全局配置，可通过Dockerfile的ENV指令预配置，或容器启动时动态注入，也可以像示例代码一样通过脚本参数显式传递。
• 权限控制：不要用root用户运行容器进程，创建普通业务用户，仅给业务目录分配必要的读写权限，避免安全风险。
• 日志配置：将子进程的标准输出、标准错误内容全部接入.NET日志系统，方便Docker日志驱动统一收集、排查问题。

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