🟡 Medium Priority

Dockerfile 第1行使用 FROM quay.io/pypa/manylinux_2_28 AS base，未指定 digest（如 @sha256:...）。

manylinux_2_28 是一个浮动标签（rolling tag），始终指向该系列的最新构建。不同时间拉取会得到不同镜像，导致：

• 构建不可重现（同一 Dockerfile、同一天构建可能得到不同结果）；
• 镜像更新可能引入不兼容的系统库变更，导致 CANN 安装或编译流程静默失败。

这是审查指南要求的关注点：unpinned base image tags。

建议：固定到特定 digest，例如 FROM quay.io/pypa/manylinux_2_28@sha256:xxxx。可以在稳定验证后锁定 digest，并在后续有计划地滚动更新。

🟡 Medium Priority

Dockerfile 第107-117行通过 wget 从远程 OBS 下载 .run 安装包后直接以 bash 执行，未做任何哈希校验（sha256/md5）。

被下载并执行的文件包括：

• Ascend-cann-toolkit_*.run（第107-108行）
• Ascend-cann-*-ops_*.run（第110-111行）
• Ascend-cann-nnal_*.run（第115-116行，条件执行）

这些 .run 文件以 root 身份执行，具有完全的系统访问权限。若 OBS 存储被入侵、网络被中间人攻击（虽然使用 HTTPS，但未做证书 pinning），或包被意外替换，恶意代码将以 root 权限在构建环境中执行，可能窃取构建环境中的凭证或污染最终镜像。

审查指南明确要求关注 wget ... | sh 类模式的安全性。虽然不是管道执行，但 wget + bash 模式本质上等效。

建议：在 wget 与 bash 之间增加哈希校验步骤。可从昇腾官方渠道获取每个 .run 文件的 SHA256 值，在 Dockerfile 中通过 ARG 传入或在脚本中硬编码期望值，使用 sha256sum -c 校验通过后再执行。同时建议对每个下载单独校验并立即清理，避免一个损坏文件影响后续步骤的清理逻辑。

🟡 Medium Priority

usage() 函数（第20-48行）函数体末尾固定执行 exit 0，忽略调用方传入的参数。

• 第85行 -h | --help 分支调用 usage 0，期望退出码 0 —— 行为正确。
• 第89行未知选项分支调用 usage 1，期望退出码非零以表示错误，但因为函数体内是硬编码的 exit 0，实际仍然以 0 退出。

后果：当用户输入非法选项时，脚本打印帮助信息但以成功状态退出，调用方（如 CI 流水线、外部脚本检测 $?）无法感知到输入错误，可能掩盖配置问题。

建议：将 exit 0 改为 exit "${1:-0}"，使调用方传入的退出码生效；同时无参调用时默认退出 0 保持兼容。

🟡 Medium Priority

builder.sh 第202行启动 dev 容器时使用 -e LD_LIBRARY_PATH=... 完全覆盖容器的 LD_LIBRARY_PATH 环境变量，而不是追加。

Dockerfile builder 阶段（第72-73行）通过 ENV 设置了 gcc-toolset 的库路径： 这是编译 OpPlugin 所必需的。dev 阶段继承该 ENV。

但当 builder.sh 启动 dev 容器时，-e LD_LIBRARY_PATH=/usr/local/Ascend/driver/lib64:... 完全替换了容器内原有的 LD_LIBRARY_PATH，gcc-toolset 路径丢失。而 .bashrc（Dockerfile 第128行）只补充 CANN 路径，不补充 gcc-toolset 路径。

对照 devcontainer.json（第26行）使用 ${containerEnv:LD_LIBRARY_PATH}:... 追加方式，正确保留了容器原始路径。

后果：通过 builder.sh 启动 dev 容器后，用户在容器内编译 OpPlugin 时，链接器找不到 gcc-toolset 提供的 libstdc++/libgcc 等库，编译可能失败。

建议：将 -e LD_LIBRARY_PATH=... 改为 -e LD_LIBRARY_PATH=/usr/local/Ascend/driver/lib64:...:\$LD_LIBRARY_PATH（注意反斜杠转义 $），使驱动库路径追加到容器原有 LD_LIBRARY_PATH 之前，同时保留 gcc-toolset 路径。这与 devcontainer.json 的做法一致。