先说结论：df 和 du 统计口径不同，差额一定能归因，不用凭感觉删文件。df 读的是文件系统已分配块总数，du 是遍历当前目录树逐个累加。楼上几位已经把已删未释放、挂载遮挡、inode、预留块讲得很全了，lsof 又查不到明显目标，下面补充几个容易漏的“隐形”占用点和一套对账方法。一、先把差额算出来假设满的是根分区（请换成 df 显示的实际挂载点）：df -B1 /sudo du -x -B1 -s / 2>/dev/null两数相减就是“du 看不到的空间”。再用 sudo lsof +L1 把已删未释放文件的大小加起来、用 tune2fs -l 看预留块，逐项扣掉，剩下的才是真正要找的。注意 du 要用 root 跑、加 -x 限定在同一文件系统，不要把报错丢掉，权限不足被跳过的目录最容易漏统计。二、容器 overlay 层：下层文件删了还在占空间如果机器跑了 Docker，容器内 rm 掉的文件并不会从镜像层消失，overlayfs 只是在上层写一个删除标记，数据块还留在 /var/lib/docker/overlay2 的下层里。容器里 du 看不到，宿主机上能看到总量：sudo du -sh /var/lib/docker/overlay2 2>/dev/nulldocker system df处理：清理无用镜像和已停容器用 docker system prune -a（会删镜像，生产环境先确认），不要直接 rm overlay2 目录。三、NFS 上的 .nfsXXXX 文件如果是 NFS 挂载目录，文件被删除时若仍有进程打开，NFS 会把它重命名为 .nfsXXXX 暂存，空间不释放。du 能统计到，但名字隐蔽，常被忽略：ls -la /挂载点 | grep .nfsfind /挂载点 -name '.nfs*' -exec ls -lh {} \;确认没有进程在用后才能删，正在用的删了会让持有它的进程出错。四、预分配文件和正在写入的文件用 fallocate 预分配、数据库或虚拟机镜像常见：文件逻辑大小不大，但已分配的块（包括未写入的 extent）很大，du 按块统计会比 ls -lh 大；反过来稀疏文件 du 又比 ls 小，不要拿 ls -lh 和 du 直接比。另外 du 是逐目录扫描的快照：扫描期间有进程在往文件里追加写，du 扫过之后文件又长大了，两次结果会对不上。用 find 直接定位大文件：sudo find / -xdev -type f -size +1G -printf '%s %p\n' 2>/dev/null | sort -rn | head五、其他几处常被忽略的占用- 交换文件：/swapfile 常数 GB，ls -lh /swapfile 看一眼。- LVM 快照：快照卷会随原卷写入而增长，用 lvs 看快照卷占用。- 回收站：桌面环境或误删进 .Trash 的文件还在，du -sh ~/.local/share/Trash /root/.local/share/Trash。- coredump 与 /var/crash：coredumpctl list 看看有没有堆积的核心转储。六、处理顺序与验证1. 先定位再动手，确认归属和业务用途再删；日志类优先截断或轮转，不要直接 rm 正在写的文件。2. 删完或截断后立刻 df -h 复核，确认 Used 下降；如果没变，说明找错地方或进程还拿着句柄。3. 根治：日志加 logrotate（copytruncate）、容器日志加 max-size、journald 设 SystemMaxUse、定期巡检 df -h 和 df -i。按“对账差额 → 容器层 / NFS / 预分配 → 其他隐形占用”这个顺序查，基本都能把差额归因到具体文件上。

结论先行：本地能登录，只证明 root 经本地通道通了；业务走的是另一条通道——另一个账号、另一个 host、另一个地址、另一份配置。按“报错定性 → 业务机复现 → 分段打勾”的顺序查，一次只改一处，每改一处复现一次。一、先看报错，定性（30 秒）- 1045 Access denied：账号、密码或 host 授权问题。- 2003 / Connection refused / 超时：监听、端口、安全组或防火墙问题。- 1049 Unknown database：库名写错，或业务账号没有该库权限。- 2059 或认证插件相关报错：客户端与 MySQL 8 默认的 caching_sha2_password 不匹配。报错不同，排查分支完全不同，先定性再动手。二、在业务机上用业务账号复现（分水岭）在业务所在机器上执行：mysql -h 业务要连的内网 IP -P 3306 -u 业务账号 -p注意 host、端口、账号要和业务配置逐字一致。如果这里能连上，问题在业务配置或连接池；如果这里也连不上，问题在数据库侧或网络侧，再往下查。三、四处对齐，按顺序打勾1. 同一个实例：同一台 ECS 上可能同时有系统包安装的 MySQL 和 Docker 里的 MySQL，改了一个、业务连的是另一个就白改。登录后核对 SHOW VARIABLES LIKE 'port'; SHOW VARIABLES LIKE 'datadir'; SHOW VARIABLES LIKE 'socket'; 再看 ss -tlnp | grep 3306，确认业务配置里的主机和端口就是这个实例。2. 同一个账号：执行 SELECT user, host FROM mysql.user; 确认业务账号存在、host 覆盖业务机 IP 或 %、账号未锁定、密码未过期。MySQL 账号是 user + host 的组合，root@localhost、root@127.0.0.1、root@% 是三个不同的账号；只改了 root 的密码，对业务用的另一个账号无效。3. 同一份配置：数据库里改完密码，业务的配置文件、环境变量或密钥配置也要同步改成新密码，改完必须重启业务或重建连接池，否则旧连接和旧密码缓存还在生效。多副本、多环境时要逐个确认，改的是线上正在跑的那份配置，而不是测试环境或容器镜像里内置的旧配置。新密码如果含有 #、$、!、@ 等特殊字符，在 shell、YAML 或 JDBC URL 里可能被转义或截断，可以先用纯字母数字的临时密码在业务机直连验证，排除这一层。4. 同一条网络路径：确认没有设置 skip-networking，bind-address 不是只绑了 127.0.0.1；ss 确认 3306 监听在业务要连的地址上；ECS 安全组入方向和本机防火墙（firewalld/iptables/ufw）放行了业务来源 IP 的 3306。内网业务优先用内网 IP，不要绕公网。四、重置流程的收尾（最容易漏）如果用 skip-grant-tables 或 init-file 方式重置，改完必须恢复正常启动并执行 FLUSH PRIVILEGES，再用业务账号验证一次，不要只在跳过授权的状态下验证。改了 my.cnf 后必须重启 MySQL 才生效，重启后核对进程启动时间晚于配置修改时间；机器上可能有多个配置文件，用 mysqld --verbose --help | grep -A1 'Default options' 确认运行实例实际读的是哪一份。五、还查不到，就看日志和连接数MySQL 错误日志会区分认证被拒绝、连接数已满还是服务启动异常，先看 SHOW VARIABLES LIKE 'log_error'; 定位日志文件。业务表现为超时或间歇性连不上时，也可能是连接池长期占满：看 SHOW STATUS LIKE 'Threads_connected'; 再对照 max_connections。收尾顺序：业务机复现并记下完整报错 → 核对实例、账号、配置是否同一套 → 查监听与安全组 → 看错误日志。每改一处复现一次，改动与结果一一对应，定位最快，也最不容易把本来好的配置改坏。

新手用 OBS 翻车的地方很集中，按下面这个“开局检查清单”逐项过一遍，大部分坑都能提前避开。一、建桶前先定好名字和区域，建完改不了桶名全局唯一，建好后不能改名、也不能换区域。建议命名带上业务、环境和区域，例如 myapp-prod-cn-north-4。对象键也先定规范：不用中文和空格，用小写字母、数字、- 或 _，按业务和日期分前缀，例如 images/2026/11/xxx.png。键名里带中文或空格，后面拼 URL、做签名、配 CDN 回源时都容易出问题。二、桶保持私有，对外分享用临时链接新建的桶默认是私有的，上传后别人打不开是正常现象。需要把单个文件发给别人时，在控制台对象详情里用“分享”生成带过期时间的临时签名 URL，不要为了图方便把整个桶改成公共读。需要长期公开访问的静态资源，单独建一个公开桶放静态文件，和业务数据桶分开。AK/SK 只留在服务端，前端直传用服务端签名或 IAM 临时凭证，绝不要写进前端代码和公开仓库。三、存储类型按访问频率选，注意最小存储时长标准存储适合频繁访问的热数据；低频访问存储适合月访问一两次的数据，最小存储时长 30 天；归档存储适合长期不访问的冷数据，最小存储时长 90 天，下载前要先发起恢复，标准恢复约 3~5 小时。低频和归档的对象如果只存几天就删，照样按最小天数计费，存短期文件反而更贵。四、大文件用分段上传，顺手配生命周期大文件上传建议走分段上传（SDK 和 obsutil 都支持自动分段和断点续传），中途失败先重试续传，不要反复从头传。分段上传中途失败或取消后，未完成的分段不会自动消失，会一直占用空间。给桶配一条生命周期规则，定期清理未完成的分段上传和过期对象；开了版本控制的桶，再配一条清理历史版本和过期删除标记的规则，否则控制台点“删除”只是打一个删除标记，旧版本照常计费。五、浏览器直传和下载，先对齐 CORS 和元数据前端直传之前，先在桶上配好 CORS 规则（允许的来源、方法和 Header），否则浏览器会报跨域错误。上传后浏览器打不开或行为不对，先看对象的 Content-Type：图片、文本缺省或不对，浏览器可能直接下载而不是预览；中文文件名下载乱码，是因为没设 Content-Disposition，改为 attachment; filename*=utf-8''xxx 这种带编码的形式。六、费用不只看存储量OBS 的账单由三部分组成：存储量、请求次数、外网流出流量。图片被别的网站直接引用、程序循环拉取对象，都会产生大量外网流量。可以在桶上配 Referer 防盗链白名单，生产流量建议前面挂 CDN 做加速和鉴权。每月到费用中心按 OBS 明细核对一次存储、请求和流量三项，比只看存储量靠谱。七、做静态网站托管，记得配首页和证书用 OBS 做静态网站托管要配默认首页（index.html）和错误页（404.html），自定义域名要先备案并配置 HTTPS 证书。不要拿 OBS 的默认域名直接当生产入口，建议走 CDN 绑定自定义域名。八、报错先分层定位报 403，先查 AK/SK 是否过期、IAM 策略和桶策略是否同时覆盖了桶和对象、是不是用了过期的临时凭证（STS）；报 404，先核对区域、桶名和对象键拼写，再用 obsutil ls obs://桶名/前缀 和 obsutil stat obs://桶名/对象键 确认对象到底在不在；浏览器报跨域，先查桶的 CORS 配置。建议：先用一个测试桶把“建桶—上传—授权—生命周期—版本清理—删除”完整走一遍，账单核对无误后再用到生产桶。

先说结论：AI 判断故障的“先后”，本质上是把各传感器事件按时间戳排序。时钟一旦有偏移或持续漂移，排出来的顺序就是错的——谁先谁后颠倒，根因结论也就跟着颠倒。而且要分清一点：时间戳的先后只能说明记录顺序，不能直接当成因果关系。一、为什么时钟不同步会直接改写顺序1. 偏移是固定差，漂移是越攒越大的差。廉价晶振误差一般在几十 ppm，50 ppm 一天就能差出约 4.3 秒；设备长期不同步、断电重启、NTP 服务不可达，误差会越攒越大。题目里振动传感器时钟慢 10 秒，系统就会把后发生的温升排到振动前面，解释成“温升引发振动”。2. 采集时间与接收时间不是一回事。传感器先采样，再经过网络上报、网关转发、平台入库；弱网、重传、队列积压都会让接收时间晚于采集时间，而且各设备的延迟不一样。如果入库时混用这两种时间戳排序，网络抖动就被当成了事件先后。3. 时区与时钟来源不一致。有的设备用 UTC，有的用本地时间，有的用 GPS 秒；跨时区、夏令时切换还会让整段记录平移一小时。4. AI 模型默认时序可信。故障根因排序、关联规则、滑动窗口分析都假设输入时间戳准确，几秒的错位会被当成真实特征学进去，先发生的被算成后发生的，相关性就反了。二、排查时先拿到三样东西1. 双时间戳。保留设备采集的 event_time 和网关/平台记录的 receive_time，只留一个时间戳等于丢了一半信息。2. 用共同事件对表。找一个所有设备都能感知到的同一事件（一次断电、一次人工触发的已知脉冲、网关重启），对比各设备日志里这个事件的时间戳，相对偏移一目了然。3. 查同步状态。看 NTP/PTP 最近一次同步时间、时钟源、漂移速率，以及重启和上次校时的记录，确认误差是固定偏移、持续漂移，还是校时后跳变。三、落地的处理方法1. 统一时间基准。全系统存储用 UTC，展示层再转本地时区；设备端定期 NTP 对时，高精度场景用 PTP（可做到亚毫秒级）；离线或无授时条件时用 GPS/北斗授时，或者设备记录本地单调递增的序列号加相对时间，由网关统一打戳。2. 设阈值、做标记。时钟偏移超过阈值（例如 500ms 或 1s，按业务容忍度定）就告警；不可信时段的数据标记为“时间不可信 / 顺序不确定”，不参与根因排序。3. 分析时放宽容忍度。对齐不上的数据扩大比较窗口，或者改用互相关、多信号联合判断，不要只看单点先后；无法可靠对齐时明确写“只能确认同时段异常”，不能把时间先后写成因果。四、一个验收办法人为注入已知偏移（例如让一台传感器的时钟快 5 秒）和网络延迟，再跑一遍诊断流程：系统应当提示时间异常或给出“顺序不确定”，而不是照常输出一个颠倒的根因结论。一句话总结：时间戳是 AI 判断故障先后的坐标轴，坐标轴歪了，结论一定是歪的。先修时间基准，再谈根因分析。

先说结论：能秒回 Permission denied，说明 TCP 22 端口已通、sshd 已应答，问题不在安全组，而在“用户名、凭证、sshd 开关”三者之一。密钥和密码同时被拒，最常见的原因是：创建实例时选了密钥登录，root 本来就没有密码，同时 PasswordAuthentication 被关了。下面按顺序排查，基本一步就能定位。 一、先用 ssh -v 定性本地执行：ssh -vvv -i 私钥路径 用户名@公网IP，盯三点：1）Authentications that can continue：如果只有 publickey，说明服务端不接受密码，换密码试也没用；2）有没有 Offering public key：没有，说明本地私钥根本没被加载——路径写错、权限过宽（会报 UNPROTECTED PRIVATE KEY FILE）、或是 .ppk 格式；3）用户名：Ubuntu 默认是 ubuntu，CentOS/openEuler 默认是 root，用错用户名，密钥再对也会被拒。 二、本地私钥：权限与格式私钥只能自己可读：chmod 600 私钥.pem。Windows 上用 PuTTYgen 生成的 .ppk，要用 Conversions → Export OpenSSH key 转成 OpenSSH 格式再用，OpenSSH 客户端读不了 .ppk。可用 ssh-keygen -y -f 私钥.pem 验证，读不出公钥就是格式或权限问题。 三、用控制台 VNC 进机器（不走 sshd）华为云控制台 → 远程登录（VNC）进去后依次查：1）sshd 是否在跑、是否监听 22：ss -tlnp | grep sshd；systemctl status sshd。2）日志直接给原因：CentOS/openEuler 看 /var/log/secure，Ubuntu/Debian 看 /var/log/auth.log，也可用 journalctl -u sshd -n 50。看到 bad ownership or modes 就是权限问题；Invalid user 就是用户名错；not allowed 就是 sshd 策略拦截。3）公钥在不在：cat ~/.ssh/authorized_keys，确认里面有你这把公钥完整的一行，不能断行、不能有多余空格，网页复制时被自动换行截断是新手最常见的坑。可用 ssh-keygen -lf ~/.ssh/authorized_keys 和本地私钥指纹比对，指纹对不上就是绑错了密钥对。4）权限链一次性修好：chmod 700 ~/.ssh；chmod 600 ~/.ssh/authorized_keys；chmod go-w ~；chown -R 登录用户 ~/.ssh。sshd 默认开 StrictModes，任一环节权限过宽都会拒收。 四、核对密钥对绑定与 sshd 生效配置先在控制台实例详情页核对绑定的密钥对是不是你手上这把；换绑或重置密钥对后，一般要按控制台提示重启实例才真正写进 authorized_keys，只点绑定不重启，实例里还是旧公钥。再以生效配置为准，不要只看 /etc/ssh/sshd_config 主文件，sshd_config.d/*.conf 会覆盖它：sudo sshd -T | grep -Ei 'pubkeyauthentication|passwordauthentication|permitrootlogin'。密钥登录要 pubkeyauthentication yes；密码登录还要 passwordauthentication yes，且 PermitRootLogin 不能是 no（Ubuntu 默认 prohibit-password 就是只许密钥、不许密码）。改完执行 sudo systemctl reload sshd，改之前保持 VNC 会话别断，另开窗口验证。 五、为什么密码登录也被拒创建实例时选“密钥对”登录，root 通常没有设置密码，密码登录必然失败——不是密码记错，而是该用户本来就没有可用密码。正确做法是在控制台对实例执行“重置密码”并按要求重启生效，同时确认上面 PasswordAuthentication 已放开。另外不要用密码反复硬试，部分镜像启用了 pam_faillock，连续失败会临时锁定账号。 六、最后复核安全组控制台安全组入方向放行 TCP 22（排查时可临时放 0.0.0.0/0，确认后收紧），并确认没有改过 SSH 端口。注意：安全组没放行时现象是连接超时，而不是秒回 Permission denied，所以它排在最后。 按这个顺序走，ssh -vvv 那一步基本就能把范围压到一个确定原因；实在进不去，控制台“重置密码”或“更换密钥对”是最快的恢复手段。

先说结论：判断的关键不是“有没有差异”，而是“差异能不能被业务事实解释”。同一套评审标准下，不同客户得分不同完全可以是正常的业务差异；只有当差异来自与任务无关的身份线索（或它的代理变量）时，才是不合理偏差。下面是可直接照做的四步排查法。 一、先划线：哪些因素允许影响评价- 允许的业务因素：写进评审标准里的硬指标，例如项目规模、历史履约记录、资质、财务数据、方案完整度。- 不允许的因素：企业名称风格、所在地（除非政策明确要求按区域适用）、法人或联系人特征、行业刻板印象等与任务无关的描述。- 做法：把评审标准写成“因素—权重—证据来源”对照表，凡是不在表里的因素，一律不允许影响分数。说不清标准，就先定标准再测模型。 二、控制变量做对照测试（反事实测试）- 准备多组材料：业务事实完全一致，只改无关描述（如企业名称、所在地表述、联系人信息）。- 同一组材料跑 3–5 次取平均（生成式模型输出有随机性，单次对比不可靠），看结论是否随无关描述变化。- 判断：业务事实不变、结论却变了，说明模型在用无关线索做判断，是偏差信号；结论稳定，则差异更可能来自业务事实本身。- 注意：对照要覆盖多种客户类型，避免拿个例下结论。 三、用指标量化差异，别凭感觉- 分组对比：在业务水平相当的前提下，对比不同客户分组的评分分布（均值、通过率）。- 差异影响比（四分之五规则）：某组通过率低于最高组的 80%，视为需要深入排查的信号。- 机会均等：业务条件相当的客户，被评为“优秀/通过”的概率是否接近。- 校准性：评分相同的客户，实际业务表现是否也相近；如果某组系统性被高估或低估，说明评分执行有偏差。- 统计显著性：样本量小时要用显著性检验或置信区间，避免把随机波动当成偏差。 四、分层定位根源：数据、提示词、评分标准- 数据层：训练或示例数据中，不同类型客户的分布是否失衡，优质样本是否集中在某一类客户上。- 提示词层：评审提示是否无意中引入标签化表述（如“龙头企业优先”），改成只描述业务事实和评分标准。- 评分标准层：人工评分员之间的标准是否一致；同一份材料，不同评分员打分差异大，说明标准本身模糊，要先对齐。- 代理变量问题：只删掉企业名称不够，地址、行业、规模等字段可能继续泄露身份。要检查“删掉敏感词之后差异是否还在”。 五、落地建议（评审场景）- 模型只做辅助：每项评价必须对应具体的项目事实和标准条款，理由写不出来就不采纳结论。- 人工复核：对评分明显偏离同组水平的案例抽查复核，发现理由不成立时修正结论。- 定期回归：每季度固定跑一次对照测试集，把分组差异指标记下来形成基线，出现漂移再排查。 一句话：先把“哪些因素允许影响评价”写清楚，再用控制变量的对照测试加分组指标验证差异来源，最后分数据、提示词、评分标准三层定位原因——能被业务事实解释的差异保留，解释不了的就修掉。

先说结论：不是账号、网络或安装包的问题，是 CodeArts Agent 这一版与 IDEA 2026.3 版本不兼容。你截图里的红字已经把原因写明了：CodeArts Agent 26.10.300 声明“Incompatible: requires IDE build 262.* or earlier”，即它只支持构建号 262.* 及更早的 IDEA。一、报错到底是什么意思1. 构建号对应关系（这点最容易搞错）：JetBrains 用构建号区分版本，261.* 对应 IDEA 2026.1，262.* 对应 IDEA 2026.2，263.* 对应 IDEA 2026.3。你截图里另一行插件的版本号 263.7307.101 也印证了当前 IDE 是 263 系列。插件声明的上限是 262.*，你的 263.* 超出范围，IDE 启动时校验不通过，就把插件标红、拒绝加载。2. 这是插件平台的硬性限制：插件在自己的描述文件里声明了支持的 IDE 构建号范围，IDE 只按这个范围放行，与你有没有登录华为云账号、网络通不通、Token 对不对都无关。3. 所以重装插件、重装 IDEA、换网络、清理缓存、重启电脑都解决不了这个问题——问题不在安装过程，而在版本声明本身。二、着急用：把 IDEA 回退到 2026.2（推荐，马上就能恢复）1. 先备份设置：File > Manage IDE Settings > Export Settings，导出一份设置；同时记下当前已装插件清单，回退后照单装回。2. 用 JetBrains Toolbox 安装 2026.2：Toolbox 支持多版本并存，不用先卸载 2026.3；也可以到官网下载 2026.2 的历史版本安装包。装好后在 Toolbox 设置里关掉 IDE 自动更新，避免它又自动升回 2026.3。3. 在 2026.2 里打开 Settings > Plugins，重新安装 CodeArts Agent 26.10.300，确认插件列表里不再出现红色 Incompatible 字样，插件状态为已启用。4. 登录华为云账号后试一次：打开一个项目，用一次 AI 问答或代码补全，能正常出结果就说明恢复了；再顺手确认常用插件都已装回。三、不着急：等插件出支持 263 的新版1. 先在插件列表里把 CodeArts Agent 禁用掉，避免每次启动 IDEA 都弹不兼容提示。2. 到 JetBrains 插件市场打开 CodeArts Agent 的页面，看版本更新记录和兼容性说明，确认新版写明支持 263.*（IDEA 2026.3）后再升级；升级顺序是先升插件、确认能用，再考虑升 IDEA。3. 等待期间如果急着用 AI 编码能力，可以先用 VS Code 版的码道插件，或者用华为云 AI 开发者空间里的现成环境顶一下，项目本身不用跟着换 IDE。四、这些做法不要试1. 不要手动改插件包里的版本声明来强行安装：绕过校验装上之后，插件在运行时仍可能调用新版 IDE 已变更的接口而报错，还会丢掉后续的正常更新通道。2. 不要在 2026.3 里装更老版本的 CodeArts Agent 指望兼容：老版本声明的支持上限只会更低。3. 不要反复重装、反复清缓存：上面已经说了，这不是安装损坏。五、以后升级前怎么做，避免再踩坑1. 升级 IDE 之前，先到插件市场看一眼主力插件的兼容性说明，确认写明支持目标版本再升级。2. IDE 和插件一次只升一个：先升一个、验证能用，再动另一个；一次改两个，出问题就分不清是谁的锅。3. 升级前导出一次设置备份；用 Toolbox 管理多个 IDE 版本并存，万一新版有问题，几分钟就能切回旧版继续干活。4. 如果回退到 2026.2 后仍提示不兼容，再把 Help > About 里的完整 Build 号和插件版本号贴出来，请大家对照着看——只说“还是不行”没法定位。总结：26.10.300 这版 CodeArts Agent 最高支持 IDEA 2026.2（构建号 262.*），你的 2026.3 是 263.*，所以被标红禁用。着急就回退 IDEA 到 2026.2，不着急就禁用插件、等支持 263 的新版。

前面几楼已经把负载画像、磁盘带宽、从小起步讲得很全了，我补充一个帖子里还没细说的角度：把选型拆成一张可落地的对照表，再用计费组合和一组数算账，这样选出来的规格不容易拍脑袋。 一、先按负载画像定实例族 不同负载缺的资源完全不同，先对上表再选规格： Web 应用、API 服务：CPU 密集加突发流量，适合通用型，CPU 与内存配比约 1:2；数据库、缓存、消息队列：内存密集型，优先保证内存配比，选内存优化型，配比约 1:8，磁盘再配高性能云硬盘；计算密集型（视频转码、批量计算、AI 推理前处理）：选计算型或通用计算增强型，CPU 配比更高；大数据、日志分析：选磁盘增强型或存储优化型，看重本地盘容量和吞吐。 两个常见错配：拿通用型跑数据库凑合，高峰期内存先瓶颈；给纯静态 Web 配内存优化型，钱花在用不上的内存上。具体规格型号以控制台实际列表为准，选型逻辑不变。 二、计费方式组合着买，比只买一种便宜 7×24 小时稳态运行的核心业务：包年包月，1 年、3 年的折扣幅度更大；长期稳定的也可以用预留实例券锁定折扣；流量波峰波谷明显的业务：按量计费加弹性伸缩和负载均衡，低峰自动缩容，只为峰值那几小时付费；无状态、可中断的离线任务（压测、批量转码、CI 构建）：竞价实例价格明显更低，但要接受系统回收的可能，任务本身做好重试和断点续跑； 一个常用组合：数据库等不好水平扩展的用包年包月大规格，应用层用按量加弹性伸缩。下单前先用华为云价格计算器把几种组合各算一遍再决定。 三、用一组数算账：别只比单价 举个例子，峰值 QPS 约 800 的 API 服务：方案 A 是 1 台 8 核 16G 包年包月，方案 B 是 2 台 4 核 8G 按量加负载均衡和弹性伸缩，低峰缩到 1 台。同样预算下应用层优先选 B：单台故障不影响业务、升级可以滚动进行、峰值还能自动加机器；单台大规格只适合数据库这类不好水平扩展的场景。 核数也别凭感觉：按峰值并发除以单核能扛的 QPS 反推核数，再按峰值 1.2 倍左右起步，跑两周看监控再调。 四、升降配写死触发条件，每月复核账单 建议把阈值写下来交给云监控和弹性伸缩自动执行：CPU 连续 7 天峰值超过 70%，或内存持续超过 80%，就升配；CPU 长期低于 20% 且内存长期低于 30%，就降配。 每月复核一次账单，顺手清理闲置弹性 IP、未挂载的磁盘、过期的快照和停用的按量实例。只看单价不看利用率，是新手最容易踩的坑。 五、10 分钟自查清单 1. 把业务的 CPU、内存、磁盘 IOPS、带宽四项需求写下来；2. 按第一节的表定实例族；3. 按第二节的表定计费组合；4. 把升降配阈值写进云监控告警和弹性伸缩策略；5. 每月复核一次规格和账单。 一句话：先画像、再对照表定实例族和计费方式、最后用监控指标和账单复核闭环，成本和性能才能同时兼顾。

前面三位把凭据类型、排查顺序和轮换流程都讲得很全了，我补充几个在实际交接中最容易被忽略的点，楼主现在这个“三个月前别人配的、自己只有编辑流水线权限”的处境正好能用上。 一、先别默认就是“过期”：401 只说明认证没通过，过期只是其中一种可能 凭据被撤销、账号改密、账号被禁用、令牌权限范围被收窄、下载步骤引用的凭据被别人换了，都会报 401。建议按这个顺序确认，而不是直接重新生成一个：1. 问项目 B 管理员：这组凭据对应的账号/令牌现在状态是否正常，有没有被重置、禁用或改过密码；2. 确认凭据的“主人”是谁：如果是离职同事的个人账号，改密、离职都会让流水线跟着挂，以后不要再用个人账号做流水线凭据；3. 确认下载步骤实际引用的是哪一组凭据，有没有被同名变量覆盖、复制时带了空格或换行。 二、交接时写清楚“谁能改什么”，能少跑很多趟 楼主只有编辑流水线权限，大概率改不了项目 B 的仓库授权，也改不了凭据本身。提申请时建议直接写明三件事：1. 需要项目 B 管理员做的事：把目标 release 仓库的只读权限，授权给项目 A 的流水线身份或专用服务账号，精确到制品路径前缀；2. 需要项目 A 管理员做的事：在凭据管理里新建或更新凭据，并让流水线引用凭据名而不是把密码写进步骤参数；3. 验收标准：一次手动构建能下载到制品，同时确认不能访问未授权的仓库。 三、轮换时留一个“双凭据重叠期” 不要先删旧凭据再建新凭据。正确顺序是：新建只读凭据 → 流水线切到新凭据 → 手动跑一次完整构建验证 → 旧凭据保留 24 到 48 小时 → 确认无其他流水线还在用旧凭据 → 再撤销旧凭据。这样即使切错了也能立刻回滚，不用在故障时重新找人开权限。 四、预检步骤只判状态码，不要输出凭据 可以在下载步骤前加一个 HEAD 预检，只记录状态码：200 通过；401 明确指向凭据问题；403 明确指向权限问题；其他状态码统一按“待排查”处理，不要在日志里打印请求头、打印完整命令，也不要把真实凭据写进脚本或工单。 五、内网还是公网：以构建机上的解析结果为准 同一区域内构建机访问制品仓库一般走内网，不产生公网流量费；跨区域会走公网。最直接的判断是在构建机上看制品域名解析到的是内网地址还是公网地址，不确定时先按跨区域估算。 总结一句话：这次先按“确认凭据主人和状态 → 项目 B 开最小只读授权 → 凭据管理里引用新凭据 → 手动验证 → 旧凭据延迟撤销”的顺序走，下次再遇到 401，就能先看预检状态码和台账，而不是等构建失败才发现。

3楼、6楼、7楼、8楼已经把权限、存储类别、Key 命名、分段上传、碎片清理、版本控制、归档恢复、费用和静态网站托管讲得很全了，我再补充几个上面几楼没展开、新手出问题后很难从报错直接看出来的坑。一、上传尺寸有硬上限，超了要换方法单次 PUT 上传最大 5GB，超过 5GB 的文件必须用分段上传；每段大小 100KB～5GB，最多 10000 个分段，单个对象最大 48.8TB。超过 5GB 的文件在控制台直接上传会失败，改用 SDK 分段上传、OBS Browser+ 或 obsutil 工具上传，支持断点续传。二、服务端加密要提前想好，事后补不上OBS 提供 SSE-OBS（OBS 托管密钥）和 SSE-KMS（KMS 托管密钥）两种服务端加密。加密只对开启后新写入的对象生效，已经存进去的对象不会自动变成加密状态，需要重新上传才生效。需要合规加密的桶，一开始就把加密方式定下来。三、对象锁定（合规保留）别误开建桶时开启对象锁定后，可以给对象设保留期限，保留期内对象不能删除、不能覆盖，适合财务、审计这类有合规留存要求的数据。普通“怕误删”的需求用版本控制就够了，不用开对象锁定，开了之后想删都删不掉。四、更新了文件，访问到的还是旧内容先查缓存，不要怀疑上传失败。OBS 直链再叠加 CDN 的场景，覆盖同名对象后 CDN 边缘节点仍可能返回旧缓存；可以在 CDN 控制台做刷新预热，或者给对象设置合理的 Cache-Control。调试时用带随机参数的 URL 或直接访问 OBS 域名对比，就能确认是缓存问题还是上传问题。五、批量操作遇到 503 SlowDown 是限流上万个对象做迁移、统计、删除时，不要用单线程循环逐个调用。正确做法是 SDK 并发加分页 List，遇到 503 SlowDown 说明请求速率触发了限流，要做指数退避重试，而不是一直重试把请求打满。六、重要桶要开访问日志和事件通知重要桶开启访问日志记录和事件通知（对象创建、删除时触发 SMN 通知），出问题时能定位是谁、什么时候删了哪个对象。日志本身也要配生命周期定期清理，避免日志桶无限增长。自查清单：超过 5GB 的文件走分段上传了吗、加密方式建桶前定了吗、保留期是不是真的需要、覆盖同名对象后有没有刷新 CDN、批量操作有没有做退避重试、重要桶的日志和通知开了吗。这几项确认好，新手阶段常见的坑基本都能避开。