用 System.IO 读取 Dockerfile 最直接，多数场景只需按行提取替换（如 FROM、ARG），避免正则全量匹配；复杂需求应使用 DockerfileParser NuGet 包解析。
用 System.IO 读取 Dockerfile 是最直接的方式
绝大多数场景下，你不需要“解析”Dockerfile 的语法结构，只需要提取或替换某几行内容（比如改 FROM 镜像、注入构建参数、更新标签）。这时候用 File.ReadAllLines 或 File.ReadAllText 就够了——简单、稳定、无依赖。
常见错误是试图用正则全量匹配指令，结果被注释、换行、引号包裹的路径搞崩。例如这行：ADD ["./src", "/app/src"]，正则若没处理好 JSON 数组格式，就会漏掉或错切。
- 优先按行读取，用
string.StartsWith("FROM ", StringComparison.OrdinalIgnoreCase)判断，别用Contains("FROM")—— 防止匹配到注释或字符串里 - 修改后写回时，用
File.WriteAllLines保持原始换行符（n或rn），否则某些 CI 环境会报 warning - 如果 Dockerfile 里有
ARG+ENV组合动态值，纯文本替换可能失效，得先做变量展开（这时才需要真正解析）
真要解析语法？别自己写，用 DockerfileParser NuGet 包
手动实现 Dockerfile 解析器成本极高：指令嵌套（如 RUN 后接多行 shell）、引号逃逸、.dockerignore 交互、平台条件（DOCKER_BUILD_PLATFORMS）都得覆盖。社区已有成熟方案。
DockerfileParser（GitHub: mikes-gh/DockerfileParser）是目前 C# 生态中最轻量且维护活跃的解析器，它把每行转成 Instruction 对象，支持增删改查。
- 安装：
dotnet add package DockerfileParser - 读取后可安全修改
FROM指令：parser.Instructions.OfType<frominstruction>().First().ImageName = "ubuntu:22.04";</frominstruction> - 注意它不执行语义校验（比如
COPY源路径是否存在），只做语法树还原 - 对 Windows 路径（
C:src）或混合斜杠（./srcsub）支持较弱，建议统一用正斜杠处理输入
RUN 和 COPY 指令修改后容易触发层缓存失效
这不是代码问题，而是 Docker 构建机制决定的：只要某一层指令内容变了，它和之后所有层都会重建。你以为只改了个版本号，结果整个 dotnet restore 又跑一遍。
典型翻车点是批量替换 ARG VERSION 后，顺手也改了紧随其后的 RUN dotnet publish -c Release -o /app/publish —— 实际上这个命令本身没变，但因上一行 ARG 改了，Docker 认为上下文变了，缓存作废。
- 只修改目标指令行，避免动相邻行（尤其是
ARG后紧跟ENV或RUN的情况） - 如果必须改多行，考虑用
docker build --no-cache=false显式控制，而不是靠文件内容触发 - CI 中建议加个校验步骤：用
git diff检查 Dockerfile 修改是否真的影响了构建逻辑，而非仅元数据
跨平台路径处理是隐形雷区
Windows 开发者常在 Dockerfile 里写 COPY .srcMyApp .，C# 程序在 Linux 容器里运行时用 File.ReadAllLines 读出来没问题，但一旦你用 Path.Combine 拼接路径再写回去，就变成 COPY ./src/MyApp . —— 表面一样，实际某些旧版 Docker daemon 会拒绝带 . 开头的相对路径（尤其在 WORKDIR 未显式声明时）。
- 永远用
/作为路径分隔符写入 Dockerfile，别依赖Path.AltDirectorySeparatorChar - 遇到
COPY --from=builder /app/out/ ./publish/这类带空格和 flag 的行，不要用Split(' ')拆，用正则^COPYs+(?<flags>(?:--w+=S+s+)*)(?<src>S+)s+(?<dst>S+)$</dst></src></flags>更稳 - 如果 Dockerfile 里用了
ONBUILD或SHELL，它们会影响后续所有指令行为，但文本替换完全感知不到——这种时候，硬改不如生成新 Dockerfile
真正麻烦的不是读或写，是判断哪一行该改、改了会不会让构建语义偏移。多数人卡在这一步，而不是技术实现。
