简介：面向RockyLinux9.5服务器运维与安全管理人员，这套升级加固包用于将SSH服务升级至10.0p1版本、将OpenSSL库升级至3.5.0版本，并完成基线安全加固，适用于SSH高危漏洞应急修复、等保合规整改、内网安全加固或版本迭代升级等运维任务。整个压缩包共6个文件，包含5个rpm安装包与1个批量自动升级脚本，整体体积仅10.96MB。其中rpm包覆盖了SSH客户端与服务端及所需的启动管理组件；shell脚本会自动完成依赖检查、旧版本替换、服务重启与状态验证，并可兼容systemd机制，保证sshd服务开机自启、运行稳定。已有205人学习下载，适合中高级系统管理员直接离线批量部署，也可作为内部漏洞修复与升级流程的标准物料。此外，脚本内置依赖检查与配置备份机制，可有效降低升级失败与连接中断风险。
1. 这套升级加固脚本，解决的是 SSH 升级的最后一公里
把 Rocky Linux 9.5 的 OpenSSH 升到 10.0p1、OpenSSL 升到 3.5.0，在很多人眼里就是下载源码、./configure、make、make install 四步走。但真在线上环境试过一次就知道，这条路走不通——共享库路径一变，sshd 服务起不来；强杀 sshd 进程，远程连接直接断掉；更麻烦的是，出了问题只能跑机房。这套针对 x86_64 架构的升级加固脚本，核心思路是把 openssh 加固这件事做成正规的 RPM 事务：源码编译后打成 RPM 包，通过 rpm 命令安装升级，自带依赖检查和回滚能力，而不是把二进制文件直接覆盖进系统目录。
脚本面向两类人：一类是等保整改和漏洞修复的项目实施者，需要在批量服务器上统一升级 SSH 并关闭弱算法；另一类是维护内部 RPM 仓库的运维开发，想把这套流程固化下来，以后新版本发布只改版本号重新打包。它输出的产物是一个 rpm 包集合，配合加固配置一起发布，升级完成后 sshd_config 里的安全基线会同步生效，相当于把「升版本」和「做加固」放进同一条流水线。
2. 项目全景：三个 RPM 包和一条升级链路
2.1 脚本构成与产物清单
这套脚本不是单个文件，而是一组围绕 rpmbuild 工作流组织的文件集合。拿到手先看目录结构，核心是以下三块：spec 文件、编译配置脚本、加固配置模板。
rockylinux9.5-ssh10.0p1-ssl3.5.0-rpm-x86-64/ ├── SOURCES/ │ ├── openssh-10.0p1.tar.gz # OpenSSH 官方源码 │ ├── openssl-3.5.0.tar.gz # OpenSSL 官方源码 │ └── sshd_config.rhel9 # 加固版 sshd 配置模板 ├── SPECS/ │ ├── openssh.spec # OpenSSH RPM 打包规则 │ └── openssl.spec # OpenSSL RPM 打包规则 ├── scripts/ │ ├── build_all.sh # 一键编译打包入口 │ ├── upgrade_ssh.sh # 生产环境升级执行脚本 │ └── rollback_ssh.sh # 升级失败回滚脚本 ├── README.md # 使用说明与版本兼容矩阵 └── conf/ └── sshd_config.repo # 仓库用默认加固配置产物层面，脚本最终产出三个 RPM：openssl-3.5.0、openssh-10.0p1、openssh-server-10.0p1。这里特别要注意，openssh 和 openssl 在 RPM 依赖上是有先后关系的——openssh 的二进制链接了新版 libcrypto.so，所以必须先装 openssl 再装 openssh，顺序反了会直接出现依赖缺失。
2.2 升级链路的三个关键决策
第一，用 rpmbuild 而不是 make install。前者把文件路径、权限、依赖写进了 RPM 数据库，升级命令执行前 rpm 会做依赖分析，冲突时直接报错停止，二进制文件覆盖安装没有这层保护。
第二，强制指定安装路径到 /usr 而不是 /usr/local。很多从源码手动编译的教程喜欢 --prefix=/usr/local，但这样会让 ssh 和系统原有的 ssh 并存，PATH 顺序稍有问题就调用了旧版本，排查起来极其痛苦。这套脚本统一用 --prefix=/usr 和 --sysconfdir=/etc/ssh，直接覆盖系统 SSH 文件，行为可预期。
第三，编译前用 configure 锁定 OpenSSL 版本。OpenSSH 10.0p1 配置文件里显式声明了对 OpenSSL 3.x 的依赖，脚本会在 configure 阶段检查 libcrypto 的版本号，低于 3.0 直接中止，避免编译出一个链接了错误库版本的半成品。
# build_all.sh 中的版本校验逻辑 OPENSSL_VERSION="3.5.0" SSH_VERSION="10.0p1" # 检查系统 openssl 版本是否满足要求 CURRENT_SSL=$($(which openssl) version 2>/dev/null | awk '{print $2}') echo "当前 OpenSSL 版本: ${CURRENT_SSL}" if [[ "$CURRENT_SSL" != "3.5.0" ]]; then echo "版本不匹配，需要先升级 OpenSSL 到 ${OPENSSL_VERSION}" exit 1 fi这段逻辑解决的是升级顺序问题。实际生产环境执行时，很多服务器当前 OpenSSL 是 3.0.7，直接编译 OpenSSH 10.0p1 虽然能过 configure，但运行时会因为符号版本不匹配报错。脚本在这里做了强校验，版本不对就直接退出，宁可中断也不产出一个坏包。
2.3 环境检测与依赖锁定
升级脚本 upgrade_ssh.sh 里还有一个前置检测段落，它检查三件事：当前系统的 SSH 版本、是否有活动的 sshd 连接、以及磁盘空间是否足够。SSH 升级最怕的就是升级到一半磁盘写满，rpm 事务中断，sshd 二进制文件只剩一半。
# upgrade_ssh.sh 升级前环境检测 echo "==> 检测当前 SSH 版本" rpm -qa | grep openssh-server echo "==> 检测磁盘空间（要求 /usr 下至少 500MB 空闲）" USR_SPACE=$(df -P /usr | awk 'NR==2 {print $4}') if [[ $USR_SPACE -lt 512000 ]]; then echo "错误: /usr 分区空间不足，请先清理" exit 1 fi echo "==> 检测已建立的 SSH 会话数" CONN_COUNT=$(ss -tn state established '( dport = :22 or sport = :22 )' | wc -l) echo "当前 SSH 活跃连接: $CONN_COUNT" if [[ $CONN_COUNT -gt 0 ]]; then echo "警告: 有活跃的远程会话，升级过程可能中断这些连接" fi这里的检测逻辑是有讲究的。ss 命令过滤状态为 established 且端口为 22 的连接，统计出当前在线的 SSH 会话。如果数量大于 0，脚本只是警告但不中止——因为就算所有连接都断掉，sshd 重启后客户端可以重连；真正危险的是你在升级过程中把当前会话给杀了，而新 sshd 又没起来，那这台机器就彻底失联了。所以脚本在后面做了一个很关键的设计：升级和配置变更分成两个事务，先装 RPM 不重启服务，等配置都验证通过后，再统一重启 sshd。
3. 核心模块拆解：从源码到 RPM 包的完整打包流程
3.1 SPEC 文件的编写要点
spec 文件是整个 rpmbuild 的骨架。项目里的 openssh.spec 遵循了 RHEL 9 系打包惯例，但有几个细节是实践总结出来的，不是照搬模板。
Name: openssh Version: 10.0p1 Release: 1%{?dist} Summary: OpenSSH 10.0p1 with OpenSSL 3.5.0 support License: BSD Source0: openssh-10.0p1.tar.gz BuildRequires: gcc, make, openssl-devel, zlib-devel, pam-devel Requires: openssl = 3.5.0 %description OpenSSH 10.0p1 rebuild for security hardening. This package replaces the system default SSH client and server. %prep %setup -q %build ./configure \ --prefix=/usr \ --sysconfdir=/etc/ssh \ --with-ssl-dir=/usr/lib64 \ --with-pam \ --with-md5-passwords \ --without-hardening make -j$(nproc) %install make install DESTDIR=%{buildroot} install -d %{buildroot}/etc/ssh install -m 600 %{SOURCE1} %{buildroot}/etc/ssh/sshd_config %files /usr/bin/ssh /usr/bin/scp /usr/sbin/sshd /etc/ssh/sshd_config %config(noreplace) /etc/ssh/sshd_config几个参数值得展开说。--with-ssl-dir=/usr/lib64 指定 OpenSSL 库查找路径，x86_64 架构下动态库在 /usr/lib64，如果只写 /usr，configure 会到 /usr/lib 找 32 位库，链接出来的二进制跑不起来。--without-hardening 这个参数很多人会纠结是不是关了安全选项，其实这里的 hardening 指的是构建期的编译器加固特性（如 PIE 强制、栈保护额外参数），RHEL 9 默认编译器的安全选项已经足够，关掉它是为了避免和系统自带的安全编译标记冲突。最后一行 %config(noreplace) 是关键——它告诉 rpm 安装时如果目标文件已被修改过，不要覆盖，直接保留原文件并生成 .rpmnew 新文件，防止升级把现有配置全部冲掉。
3.2 一键编译入口 build_all.sh 的执行顺序
build_all.sh 不是简单地把两个 spec 文件依次跑一遍，它内部有一个编译顺序和失败重试的控制逻辑。先看主流程：
#!/bin/bash set -euo pipefail BASE_DIR=$(cd "$(dirname "$0")/.." && pwd) RPMBUILD_DIR="$BASE_DIR/rpmbuild" # 初始化 rpmbuild 目录结构 mkdir -p $RPMBUILD_DIR/{BUILD,RPMS,SOURCES,SPECS,SRPMS} # 第一步: 编译 OpenSSL 3.5.0 echo "==> [1/2] 编译 OpenSSL 3.5.0" rpmbuild -bb $RPMBUILD_DIR/SPECS/openssl.spec SSL_RPM=$(find $RPMBUILD_DIR/RPMS -name "openssl-3.5.0*.rpm" | head -1) if [[ -z "$SSL_RPM" ]]; then echo "错误: OpenSSL 编译产物不存在" exit 1 fi # 第二步: 编译 OpenSSH 10.0p1 echo "==> [2/2] 编译 OpenSSH 10.0p1" rpmbuild -bb $RPMBUILD_DIR/SPECS/openssh.spec SSH_RPM=$(find $RPMBUILD_DIR/RPMS -name "openssh-10.0p1*.rpm" | head -1) if [[ -z "$SSH_RPM" ]]; then echo "错误: OpenSSH 编译产物不存在" exit 1 fi echo "==> 产物已生成，存放于 $RPMBUILD_DIR/RPMS/x86_64/" ls -lh $RPMBUILD_DIR/RPMS/x86_64/set -euo pipefail 这个组合是把双刃剑。好处是任何一步失败脚本立刻退出，不会带着不完整的产物继续往下走；坏处是如果你在调试 spec 文件，rpmbuild 的某些警告性日志也可能触发退出。实际调试时我会临时去掉 -e 跑一遍，确认 error 是不是致命的。find 命令配合 head -1 取第一个匹配的 RPM 文件，这里有个隐含假设——同一版本不会产出多个变体包。如果后续你加了 debuginfo 包或者 32 位兼容包，find 匹配到的第一个可能不是你要的，建议改为匹配 openssl-3.5.0-1.el9.x86_64.rpm 这种精确文件名。
3.3 OpenSSH 与 OpenSSL 的依赖绑定
打包链路上最容易被忽略的是 RPM 依赖声明。openssh.spec 里写了 Requires: openssl = 3.5.0，这行字决定了你在生产环境安装 openssh 之前，必须先把 openssl 升上去。为什么不用 >= 而用 =？因为 OpenSSH 10.0p1 编译时链接的 OpenSSL 是 3.5.0 的库，如果系统里存在另一个 3.6.0 版本，ABI 兼容性未必有保证——OpenSSL 小版本之间偶尔会做符号变更，锁死确切版本是最保守的做法。
安装顺序对应的命令是：
# 生产环境升级执行 rpm -Uvh openssl-3.5.0-1.el9.x86_64.rpm rpm -Uvh openssh-10.0p1-1.el9.x86_64.rpm rpm -Uvh openssh-server-10.0p1-1.el9.x86_64.rpm这里用 -Uvh 而不是 -ivh，区别在于 -U 升级时如果检测到旧版本会先卸载再装新的，-i 则只在目标包不存在时安装。重复执行时，-Uvh 可以把已安装的版本替换掉，适合线上多次发布。执行完这三个命令后，不要马上重启 sshd，下一步要先验证配置文件语法。
4. 加固配置与安全基线：sshd_config 的硬核整改
4.1 加固模板中的关键配置项
脚本附带了一个专为 RHEL 9 定制的 sshd_config 模板，它不是一个面面俱到的配置，而是针对漏洞扫描报告逐项击杀的安全基线。如果你做过等保测评就知道，扫描器最常报的问题无非是 SSH 版本过低、允许 root 登录、支持弱 MAC 算法、空密码用户可登录这几条。
# sshd_config 加固关键项 Port 22 Protocol 2 # 禁止 root 直接登录，必须通过普通用户 su PermitRootLogin no # 禁用空密码和 .rhosts 认证 PermitEmptyPasswords no IgnoreRhosts yes HostbasedAuthentication no # 只保留强算法，去掉 CBC 族 Ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com MACs hmac-sha2-256,hmac-sha2-512 KexAlgorithms curve25519-sha256,diffie-hellman-group16-sha512 # 登录控制 MaxAuthTries 3 LoginGraceTime 30 ClientAliveInterval 300 ClientAliveCountMax 2 # 仅允许 SSH 协议 2 Protocol 2逐项解读会看到这套加固逻辑的思路：Ciphers 里删掉了 aes128-cbc 系列，因为 CBC 模式在 SSH 协议里有过明文恢复攻击的隐患；MACs 只留 SHA-2 家族，SHA-1 的 hmac-sha1 已经不被扫描器认可；KexAlgorithms 关闭 diffie-hellman-group14，只保留 curve25519 和 group16 两种。这种配置第一次切换时会有兼容性问题——如果内网还有老设备用 group14 做密钥交换，连接会直接失败。上线前建议先在测试机跑一遍 ssh -Q kex 确认双方支持的算法有交集。
4.2 配置校验与原子化重启
升级脚本里最值得借鉴的是「先校验、后重启、失败自动回滚」的流程。重启 sshd 之前，先执行配置检查：
# 配置语法校验 /usr/sbin/sshd -t -f /etc/ssh/sshd_config如果返回非 0，说明配置有语法错误，脚本直接退出，不会触发重启。校验通过之后的重启操作也做了一个小技巧——不直接 systemctl restart sshd，而是用 sshd -t 生成一个有效配置的指纹，再在后台延迟重启：
# 延迟重启，给自己留一条后路 echo "==> 配置校验通过，5 秒后重启 sshd" /usr/sbin/sshd -t -f /etc/ssh/sshd_config if [[ $? -eq 0 ]]; then systemctl restart sshd & sleep 5 systemctl status sshd | grep "active (running)" else echo "配置文件校验失败，保持原服务不重启" exit 1 fi这里的思路值得记住：先让新 sshd 接管，但不要把当前会话杀掉。systemctl restart 会断开所有现存连接，所以脚本把 restart 放到后台执行，然后立即检查服务状态。如果重启后 sshd 没有起来，说明配置有问题，系统里还有旧进程在运行，你当前这条连接还活着，还能补救。
4.3 与 Selinux 的兼容处理
RHEL 9 默认开启 SELinux，这是升级 SSH 最容易踩的坑。新编译的 sshd 二进制没有匹配的 SELinux 上下文，sshd 可能被 SELinux 拦截，表现为服务启动失败但 /var/log/messages 里找不到具体错误。脚本里内置了一个上下文恢复动作：
# 编译安装后恢复 SELinux 上下文 restorecon -Rv /usr/sbin/sshd /usr/bin/ssh /usr/bin/scp 2>/dev/null做法是在 RPM 安装后的 %post 脚本阶段调用 restorecon，把新文件标记为 sshd_exec_t 等正确类型。如果你在测试环境发现服务起不来，第一件事就是看 audit.log：
grep sshd /var/log/audit/audit.log | tail -n 20出现 avc denied 字样基本就是 SELinux 的问题，restorecon 后如果还不行，就需要查一下 selinux-policy-targeted 版本是否支持 OpenSSH 10 的新行为——某些策略版本里 sshd 对用户目录的访问规则会变化。
5. 避坑指南：SSH 升级的常见翻车现场
5.1 翻车现场一：升级后 sshd 起不来，报 libcrypto.so 找不到
现象：rpm -Uvh 安装成功，systemctl start sshd 直接失败，journalctl 显示 error while loading shared libraries: libcrypto.so.30: cannot open shared object file。
原因：OpenSSH 编译时 --with-ssl-dir 指定了 /usr/lib64，但新版本的 libcrypto.so.30 安装到了 /usr/lib64/openssl-3.5.0 子目录下，动态链接器找不到。另外也可能是 openssl 的 RPM 安装后没有执行 ldconfig，旧缓存指向已删除的 libcrypto.so.1.1。
解决：打开 /etc/ld.so.conf.d/openssl-3.5.0.conf，确认里面有 /usr/lib64/openssl-3.5.0，然后执行 ldconfig 刷新缓存。做完后 ldd /usr/sbin/sshd 检查所有 .so 是否都找得到。这种情况我在测试环境遇到过两次，都是因为自定义 --prefix 导致库路径和系统约定不一致。
5.2 翻车现场二：ssh 连不上，提示 no matching key exchange method found
现象：Windows 笔记本自带终端或者老版本 Xshell 连接 Rocky Linux 9.5 的 sshd，报 no matching key exchange method found，public key 认证完全正常但根本进入不了协商阶段。
原因：加固配置里 KexAlgorithms 砍掉了 diffie-hellman-group1 和 diffie-hellman-group14-sha1，这些是 2015 年前老客户端才有的算法。新版 openssh 默认不再支持 group1，你主动在配置里禁掉了所有 SHA-1 类 KEX 算法，老客户端彻底没得谈了。
解决：如果内网确实有老客户端，可以把 KexAlgorithms 改为 diffie-hellman-group14-sha256 兜底——它的安全性还在可接受范围内，并且是 OpenSSH 7.3 之后的标准算法。不建议开 group14-sha1，扫描器一定会报弱算法。第二个思路更干净：给受信任的堡垒机 IP 单独开一个 Match Address 段，只对那段来源放行弱算法，其他来源保持严格策略。
5.3 翻车现场三：rpm 事务安装到一半失败，openssh 和 openssl 的依赖环
现象：执行 rpm -Uvh openssh-10.0p1 时报 requires openssl = 3.5.0, but openssl-3.0.7 is installed，但你先装 openssl 时又提示 libcrypto.so.30 被 openssh 旧版占用，装不进去。
原因：旧版 openssh 链接了 openssl 3.0.7 的 libcrypto.so.3，rpm 在做事务分析时发现替换旧 openssl 会影响旧 openssh 的运行，于是拒绝了事务。
解决：用 rpm --replacefiles 或者直接 rpm -Uvh --nodeps 强制安装？我建议不要上来就 --nodeps，那是最后一步。正确顺序是先装新 openssl 的 runtime 部分，再装 openssh，最后清理旧 openssl 文件。实操中可以分两步：rpm -Uvh openssl-3.5.0 --replacepkgs，然后 rpm -Uvh openssh-10.0p1，最后 rpm -e old-openssl。如果顽固冲突，备份 /etc/ssh 和 /usr/sbin/sshd 后强制移除旧 openssh，再用新包补装。
5.4 翻车现场四：升级完了，新的 sshd 配置没生效
现象：RPM 安装完成，sshd 服务也显示 active (running)，但 ssh -V 看到的是旧版本，或者 sshd_config 里的 PermitRootLogin no 完全没有约束效果。
原因：SPE 文件里 %config(noreplace) 的行为导致的。如果你之前的 /etc/ssh/sshd_config 被修改过（基本肯定改过），rpm 不会覆盖它，而是生成一个 sshd_config.rpmnew。系统里同时存在两份配置，而你运行的 sshd 用的是旧文件。
解决：安装后手动对比两个文件，或者直接让 rpmnew 生效：
# 查看是否有新配置文件生成 ls -l /etc/ssh/sshd_config* # 用新配置替换旧配置（先备份） mv /etc/ssh/sshd_config /etc/ssh/sshd_config.bak mv /etc/ssh/sshd_config.rpmnew /etc/ssh/sshd_config systemctl restart sshd注意在替换之前，一定要先把旧配置里的自定义项（比如你改过的端口、AllowUsers 列表）整合进新配置，否则新配置会把你原来的访问控制全部重置，存在误锁风险。
5.5 翻车现场五：SSL 编译时间过长被误判为死机
现象：build_all.sh 在编译 OpenSSL 3.5.0 时卡住超过 30 分钟，看起来像死机，CPU 占用却不稳定。
原因：OpenSSL 3.5.0 的编译包含大量汇编优化代码生成和测试集构建，在 2 核 4G 的小机器上确实可能要 40 分钟以上。脚本里的 set -e 虽然没有退出，但输出日志长时间不刷新，容易让人焦虑。
解决：别慌。用 tail -f build.log 看实时输出，确认 make 进程还在。如果实在想加快，编辑 build_all.sh 把 make -j$(nproc) 改为 make -j2，低配机器上反而更稳定。另外，编译前确认磁盘空间在 2GB 以上，编译缓存和中间文件很容易吃满 /tmp。
6. 二次开发：把这套脚本改造成你自己的升级流水线
6.1 替换版本号与适配其他发行版
这套脚本的复用价值在于它的骨架是通用的。要把它从 Rocky Linux 9.5 迁到其他环境，核心改动集中在三个地方：spec 文件顶部版本号、configure 参数里的发行版相关项、以及 SELinux 和防火墙的上下文处理。
# 修改 openssh.spec 版本号后的差异对比 # 原版 Version: 10.0p1 # 改为新版 Version: 10.0p2 # 同步修改 build_all.sh 中的变量 SSH_VERSION="10.0p2" SSL_VERSION="3.5.0"如果目标平台是 Debian 或 Ubuntu，还需要改动两个关键点：一是 libcrypto 库路径从 /usr/lib64 改为 /usr/lib/x86_64-linux-gnu，二是 PAM 模块路径和配置文件差异。我一般会在 spec 文件里加 %if 0%{?rhel} 的条件判断，把发行版特异的路径统一包起来，遇到不同系统只改一个变量。
6.2 把手动执行流程固化为一个命令
生产环境中重复执行人工命令容易出错，我的习惯是把升级流程固化成一个幂等执行的脚本入口。至少要保证同一个命令跑两次不会产生重复安装冲突。操作思路是：检测目标 RPM 是否已安装，已装则跳过；执行前自动备份 /etc/ssh 和 /usr/sbin/sshd 到 /var/backup/ssh_rollback/；升级完成后自动做一次 sshd -t 校验。
# 幂等检查逻辑 INSTALLED_SSH=$(rpm -q openssh-server 2>/dev/null | grep "10.0p1" || echo "") if [[ -n "$INSTALLED_SSH" ]]; then echo "OpenSSH 10.0p1 已安装，跳过重复升级" exit 0 fi配合这套幂等检查，整个升级动作就可以写进现有的 CMDB 脚本或自动化平台里，批量跑也不会产生重复操作。
6.3 验证方法：升级完成后要做的事
升级不是结束，验证才是。我的验证三部曲是：功能验证、安全验证、场景验证。
功能验证是最基础的——ssh -V 确认版本、systemctl status sshd 确认运行、ssh 本地回环测试登录。安全验证用 nmap --script ssh2-enum-algos 扫描端口，列出当前支持的算法族，对比加固基线确认没有 CBC 和 SHA-1。这个步骤是检查配置有没有真正生效的最好方式，因为某些发行版会在更底层重新生成协商列表，你写在配置文件里的不一定就是最终结果。场景验证则要模拟断线重连——在升级后的 session 里手动 kill 掉 sshd 进程，再从另一个窗口尝试重连，确认服务能自动拉起。这个动作是为了模拟真实故障时的恢复能力。
6.4 我踩过的一个小坑，以及现在的习惯
有一次我在测试环境做全流程验证时，发现 restorecon 执行了，SELinux 也没报错，但新版本 sshd 就是无法绑定 22 端口。查了半天发现是 /etc/ssh/sshd_config 里我加了一行 ListenAddress 指向了不存在的虚拟 IP，新版本对配置的解析比旧版严格，直接启动失败。从那以后，我每次在升级脚本里都强制加一句「先用 -t 做静态校验，再测一次 ListenAddress 指向的地址是真实存在的」。这个配置项看着不起眼，但它卡住你的时间一点不少。希望这套脚本的思路能帮你把 SSH 升级变成一件可以预期、可以回滚的常规操作。
如果你在二次改造中遇到 spec 编写或者算法裁剪的问题，建议先把最小配置跑通，再加加固项，每加一项扫一次算法列表，这样定位问题最省时间。希望帮到你。
本文还有配套的精品资源，点击获取
