按"文件类型"分成四类，每类给最省事的方法。先说结论：代码用 Git、配置用 scp/rsync、大文件用 OBS、整机用快照。一、代码和项目文件：用 Git（首选）这是最推荐的方式，因为不只是"备份"，还有版本历史和回滚能力。cd ~/projectgit init && git add -A && git commit -m "init"git remote add origin 你的仓库地址>git push -u origin main然后在本地 git clone 拉下来。优点：支持增量、有历史、换机器方便。注意：.env、密钥文件不要提交，务必配好 .gitignore。二、少量配置文件/脚本：scp 或 rsync· 单文件：scp -r user@host:~/config ./backup/· 整个目录、要增量：rsync -avz --progress user@host:~/data/ ./backup/data/rsync 只传变化的部分，重复执行很快，适合做成定时任务。Windows 本地可以用 WinSCP（图形化）或 WSL 里的 rsync。三、数据文件/大文件：传到 OBS云主机和 OBS 在同区域时走内网，不消耗公网流量、速度快。· 命令行工具 obsutil：./obsutil cp -r ~/data obs://your-bucket/backup/2026-10-25/· 或者用 SDK 写个脚本，配合 crontab 每天增量同步。优点：容量大、便宜、可跨区域容灾；缺点：需要配 AK/SK（建议用临时凭证或 IAM 子账号最小权限）。四、整机/系统状态：用快照如果目的是"整台机器挂了能快速恢复"，那文件级备份不够，要用云硬盘快照：· 控制台对系统盘/数据盘创建快照，可以按策略每天自动打；· 恢复时用快照回滚或新建磁盘挂载；· 注意快照是增量存储，第一次大、后续增量，成本可控。适合：环境配置复杂、重装成本高的开发机。五、几种组合方案（按重要程度选）方案 A：日常轻量（推荐给多数人）代码推 Git + 配置目录每天 rsync 到本地 + 数据目录每周传 OBS。方案 B：自动化（无人值守）写一个 backup.sh，用 crontab 定时执行：# 每天 02:00 备份0 2 * * * rsync -az ~/work /backup/local/ >> /var/log/backup.log 2>&10 3 * * 0 obsutil cp -r -f -u ~/data obs://bucket/weekly/ >> /var/log/backup.log 2>&1关键点：日志要留（否则失败了都不知道）、要有失败告警（比如失败时发邮件/写企业微信机器人）。方案 C：容灾级快照策略（每日）+ 跨区域复制到另一个 OBS 桶 + 关键数据本地再留一份。三副本，任何单点故障都不怕。六、五个容易忽略的点1. 备份没验证等于没备份：定期真的从备份里恢复一次，确认能打开、文件完整；2. 注意权限和隐藏文件：rsync -a 才会保留权限和时间戳，scp 默认会丢；点开头的隐藏文件（如 .bashrc、.config）容易被漏掉；3. 云主机可能被回收：开发者空间的免费云主机有生命周期限制，重要数据不要只放在上面，本地或 OBS 必须有一份；4. 传输中断：大文件用 rsync --partial --append-verify 支持断点续传，或用 obsutil 的分段上传；5. 备份也要有保留策略：本地备份目录会越滚越大，定期清理旧版本（保留最近 7 天 + 每月 1 份）。我的建议：如果只是"防止云主机到期丢东西"，Git + 每周 obsutil 同步 + 每月一次本地全量就够了，投入最小、覆盖最全。如果环境配置很值钱（装了几十个工具、调了很久），再加一个每周自动快照。

会，而且会继续收费。这是 OBS 版本控制最常见的一个认知误区——"删除"在开启版本控制后不等于"释放空间"，只是给对象加了一个删除标记。一、为什么删了还占容量开启版本控制后，OBS 对每个对象维护多个版本：· 你执行"删除"时，默认操作是插入一个删除标记（Delete Marker），不删除任何历史版本；· 列表里看不到该对象了，但所有历史版本仍然存在并占用存储容量；· 计费按所有版本的实际存储字节算，不是按"当前可见对象"算。所以如果这个对象历史上被覆盖过 10 次，占的是 11 份（10 个版本 + 1 个删除标记）的容量。二、怎么确认到底占了多少· 控制台：对象列表里开启"显示历史版本"，能看到每个对象的全部版本和各自大小；· 桶的用量统计：看"存储用量"和"对象数量"，如果对象数量远大于你感知的文件数，基本就是历史版本堆积；· API/SDK：ListObjectVersions 可以列出所有版本，统计各版本 Size 求和；· 计费中心：看 OBS 存储费的用量明细，按存储类别（标准/低频/归档）分别列示。三、真正释放空间的做法核心概念：删除"具体版本"，而不是删除"对象"。· 普通删除 → 加删除标记，空间不释放；· 删除指定版本（要带 versionId）→ 真正删除该版本的数据，空间释放；· 删除删除标记 → 对象"复活"成上一个版本（注意这不是释放空间，反而会让对象重新可见）。批量清理的推荐方案：生命周期规则手工删版本不现实，正确做法是配生命周期：1. 过期删除历史版本：规则里设置"非当前版本在 N 天后删除"（例如保留 30 天），这是最有效的一条；2. 清理过期删除标记：设置"删除标记在 M 天后自动清理"，避免删除标记本身堆积（删除标记虽然不计存储费，但会占对象数量配额、干扰列举）；3. 配合前缀和标签：只对特定目录（如 logs/、tmp/）生效，别对全部对象一刀切，防止误删重要历史版本；4. 先试运行：多数平台的生命周期规则支持预览"将影响多少个对象"，配完先看预估影响面再启用。四、几个容易踩的坑· 以为关了版本控制就释放了：关闭版本控制不会删除已有历史版本，历史版本依然计费且依然存在，必须显式清理；· 只删了删除标记：这样对象会重新出现，看起来像"删不掉"，其实是操作方向反了；· 跨存储类别忽略：低频/归档存储的历史版本同样计费，而且归档取回还有额外费用，清理时别漏；· 碎片/分段上传残留：大文件分段上传失败会留下未完成的分片，这部分也占容量，同样需要生命周期规则清理；· MFA Delete：如果桶开了 MFA 删除保护，删除版本需要 MFA 凭证，自动化清理脚本会失败，要提前确认。五、成本角度的建议1. 版本控制不是免费的保险：它防误删很有效，但代价是存储成本可能翻几倍。上线前先估算"日均覆盖次数 × 平均对象大小 × 保留天数"；2. 分层保留：重要数据保留 90 天历史版本，临时数据（日志、缓存、构建产物）保留 3~7 天甚至不开启版本控制；3. 定期体检：每月看一次"对象数 vs 实际文件数"的比值，比值异常升高说明有版本堆积或碎片；4. 删除前先快照：清理历史版本是不可逆操作，重要桶建议先做一次跨区域复制或下载清单留档。一句话结论：开启版本控制后，"删除"只是打了个标记；要真正省钱，必须用生命周期规则清理非当前版本和未完成的分片，并且定期核对对象数与存储用量。

这个症状很典型：回源是对的、CDN 返回是错的，说明缓存键没把图片处理参数算进去，CDN 把 A 尺寸的响应缓存下来，之后请求 B 尺寸直接命中了 A 的缓存。一、先确认现象· 直接访问 OBS 源站（不走 CDN）用同样的处理参数，返回尺寸正确 → 源站没问题，问题在 CDN 缓存层；· 同一个 URL 第一次请求正确、刷新几次后变成错误尺寸 → 典型的缓存污染；· 加个随机 query 参数（如 &_t=123）后恢复正常 → 进一步坐实是缓存键问题。二、根因：缓存键没包含处理参数OBS 图片处理有两种写法，缓存键的处理方式完全不同：① query 参数式https://cdn.example.com/a.jpg?x-image-process=image/resize,w_200很多 CDN 的默认缓存键只取"协议+域名+路径"，query 被忽略。这时 200 和 800 两个请求算同一个键，先到先缓存，后到的全部拿到错误尺寸。解决：在 CDN 的缓存键配置里把 x-image-process 加入"保留查询参数"白名单。注意是白名单而不是"全部保留"——全部保留会让 _t 之类的随机参数把缓存打散，命中率暴跌。② 样式（style）式https://cdn.example.com/a.jpg!style200 或 ?style=style200如果样式名写在路径里（!style200），路径本身就参与缓存键，通常不会出问题；写在 query 里则同样需要加白名单。三、推荐的缓存键配置· 保留参数：只保留 x-image-process（或你的 style 参数名），不要保留 _t、utm_*、spm 等跟踪参数；· 忽略大小写：处理参数严格区分大小写，建议 CDN 侧对参数名做规范化，避免 W_200 和 w_200 产生两份缓存；· 参数顺序归一：?a=1&b=2 和 ?b=2&a=1 语义相同但键不同。如果 CDN 支持参数排序，开启后能显著提升命中率；· 缓存时长要分层：原图可以长缓存（7~30 天），处理后的图建议短一些（1~7 天），因为样式模板可能会调整。四、还有一个容易忽略的点：Vary 头如果图片处理依赖请求头（如 Accept: image/webp 做格式自适应），必须在 CDN 配 Vary: Accept，否则 WebP 和 JPEG 会互相污染缓存。但 Vary 会降低命中率，更好的做法是把格式做成路径或参数的一部分（如 ?format=webp），而不是依赖请求头协商。五、修复步骤1. 修改 CDN 缓存键配置，把 x-image-process 加入保留参数白名单；2. 刷新已污染的缓存：按 URL 刷新或按目录刷新（注意：只改配置不刷新，错误响应还在缓存里，看起来像"没生效"）；3. 验证：连续请求两个不同尺寸的 URL，分别看返回的 Content-Length 和实际图片像素，确认各自正确；4. 观察命中率：改完后看 CDN 命中率曲线，如果明显下降，说明白名单里混进了不该保留的参数。六、长期建议· 把常用的尺寸固化成样式模板（style），前端只传样式名不传原始参数，既避免参数写法五花八门，也让缓存键更稳定；· 前端不要在处理参数后面拼时间戳做"防缓存"——那会把 CDN 缓存彻底废掉，正确的做法是图片内容变了就换文件名（内容哈希命名）；· 上线前用 curl -I 看 X-Cache（或平台对应的命中标识）和 Content-Length，两个尺寸的响应长度应该不同，这是最直接的验收方法。

流水线依赖缓存"配了但不生效"，绝大多数不是缓存服务坏了，而是缓存键（key）算出来每次都变，或者存/取路径对不上。按下面五步定位，基本能一次找到原因。一、先确认缓存到底有没有被命中这一步最容易被跳过。看两个地方：· 构建日志：缓存步骤通常有 "cache hit" / "cache miss" 或 "restore cache" 的日志行，先确认是 miss 还是 hit；· 耗时对比：命中缓存时 npm ci 通常几秒完成，未命中要几十秒到几分钟。耗时没变化基本就是没命中。二、最常见的五个原因1. 缓存键里带了每次都变的变量这是第一大坑。例如 key 写成 npm-$CI_BUILD_ID 或包含了时间戳/commit SHA，那每次都必然 miss，等于没配。正确做法：key 应该由"输入内容的指纹"决定，典型的用 lockfile 的哈希：key: npm-${{ hashFiles('**/package-lock.json') }}这样只有依赖真正变化时才失效。2. 缓存路径和实际安装路径不一致Node.js 项目缓存的是 node_modules 还是 npm 的全局 cache 目录（~/.npm），两者策略不同：· 缓存 node_modules：恢复快，但平台/Node 版本变化时容易出兼容问题，跨操作系统不可复用；· 缓存 ~/.npm（包管理器的下载缓存）：通用性好，配合 npm ci --prefer-offline 效果更稳。建议优先缓存 ~/.npm 而不是 node_modules，踩坑少。同时确认路径写的是绝对路径，且和后面安装命令实际写入的位置一致。3. 缓存作用域（scope）不对很多平台的缓存默认只在同一分支内可见。如果你在 feature/xxx 分支构建，读不到 main 分支的缓存，表现就是"第一次永远慢"。处理方式：在缓存配置里显式指定回退分支（如 restore-keys 或平台对应的"允许从默认分支恢复"选项）。4. 缓存有 TTL，或者被容量策略淘汰· 平台通常有缓存保留期（7 天/30 天不等），项目不常构建就会过期；· 缓存容量有上限，超了会按 LRU 淘汰旧缓存。一个 node_modules 动辄几百 MB，多分支并行构建很快就把配额撑满，互相把对方挤掉。检查方式：看平台缓存管理页的占用和命中率曲线，命中率突然掉下来通常就是被淘汰了。5. 步骤顺序错了必须先恢复缓存，再执行安装。如果 npm ci 写在恢复缓存之前，那缓存恢复了也没用；反过来如果是"先装再存"，那存进去的是全新下载的产物，下次能命中但第一次永远是冷的。另外注意：npm ci 会删除 node_modules 重新安装，所以缓存 node_modules 时用 npm ci 反而会丢掉恢复的内容——这种情况改用 npm install 或改缓存 ~/.npm。三、快速验证方法1. 把缓存 key 临时写死成一个固定字符串（如 npm-debug-v1），连跑两次：· 第二次仍然慢 → 问题在路径或步骤顺序；· 第二次变快 → 问题在 key 计算，回去检查 hashFiles 的匹配路径。2. 在构建日志里 ls -la 一下缓存目录，确认恢复后目录里确实有文件、文件数量符合预期。3. 对比两次构建的 key 实际取值（日志里一般会打印），看是否一致。四、清缓存之外的根治方向· 锁死 Node 版本：用 .nvmrc 或 engines 字段固定版本，避免基础镜像升级导致缓存全部失效；· 把 key 的维度想全：hashFiles('package-lock.json') 之外，还要拼上 Node 大版本和操作系统，例如 npm-node20-linux-${{hashFiles('package-lock.json')}}，避免跨环境复用出诡异问题；· 分拆缓存粒度：monorepo 场景下按子包分别缓存，别一个大缓存包打天下，一个包变了全部失效；· 用包管理器的离线优先模式：npm ci --prefer-offline --no-audit，即使缓存部分命中也能省掉大量网络请求。结论：先看日志确认 hit/miss，再查 key 是否稳定、路径是否对、分支能否读到、容量是否被挤掉、步骤顺序是否合理。这五项按顺序排查，90% 的"缓存不生效"都能定位到具体一条。

可以，开发者空间的云主机支持 SSH 远程连接，本地 VS Code 用 Remote - SSH 插件连上去体验基本和本地一样（能开终端、装扩展、调试、端口转发）。下面给完整步骤和几个必踩的坑。一、前置条件（先确认这三件事）1. 云主机已启动，且能拿到公网 IP 或已开通公网访问方式（开发者空间通常提供公网访问入口，或通过 Web 终端）；2. 知道登录用户名和端口（默认 22，若改过端口要记准确）；3. 有一对可用的 SSH 密钥，或知道密码（部分环境禁用密码登录）。二、连接方式一：标准 SSH 密钥方式（推荐）1. 本地生成密钥（如果还没有）：ssh-keygen -t ed25519 -C "dev-space"2. 把公钥 ~/.ssh/id_ed25519.pub 的内容追加到云主机用户目录下的 ~/.ssh/authorized_keys。没有公钥上传入口时，先在 Web 终端里手动写入：mkdir -p ~/.ssh && chmod 700 ~/.sshecho "ssh-ed25519 AAAA... dev-space" >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys3. 本地测试连通：ssh -i ~/.ssh/id_ed25519 -p 22 用户名>@主机地址>4. 配置 ~/.ssh/config 简化命令：Host devspace HostName 1.2.3.4 User root Port 22 IdentityFile ~/.ssh/id_ed25519 ServerAliveInterval 605. VS Code 安装 Remote - SSH 扩展 → 按 F1 → Remote-SSH: Connect to Host → 选 devspace。连上后左下角会显示远程主机名，此时打开的文件夹、终端、调试器全部在云主机侧运行。三、连接方式二：只有 Web 终端、没有公网 SSH 端口时开发者空间的部分环境默认不开放公网 22 端口，这时有两种做法：① 用 VS Code 的端口转发 + Web 终端反向隧道（如果环境支持）：在云主机侧执行ssh -R 0:localhost:22 你的中转服务器>然后在本地通过中转服务器跳进去。② 用 VS Code 的隧道功能（code tunnel）：在云主机 Web 终端里执行code tunnel按提示用 GitHub/Microsoft 账号授权，之后本地 VS Code 用 Remote-Tunnels 连接即可，完全不需要开放任何入站端口。这是穿透内网/无公网 IP 场景最省事的方式。四、五个常见坑1. 连不上先分清是"超时"还是"refused"：超时=网络/安全组拦了，refused=sshd 没起或端口不对。两种情况排查方向完全不同。2. 安全组要放行源 IP：把本地出口 IP 加到 22 端口的白名单（x.x.x.x/32），别图省事开 0.0.0.0/0。3. 权限问题导致密钥失效：~/.ssh 必须是 700，authorized_keys 必须是 600，权限过宽 sshd 会直接忽略密钥且不报错——这是最隐蔽的坑。4. 远程端 VS Code Server 装不上：常见于磁盘满、/tmp 不可执行、或无法访问外网下载 server 包。解决：df -h 看磁盘，或在本机下载 vsix 后手动安装。5. 连接频繁断开：加 ServerAliveInterval 60 和 ServerAliveCountMax 3，防止 NAT 空闲超时；另外确认云主机没有被自动休眠/回收策略影响。五、连上之后建议马上做的几件事· 装 Remote - Containers（如果项目用容器），开发环境和生产保持一致；· 把 ~/.vscode-server 所在磁盘做容量监控，扩展装多了会吃掉几个 G；· 配置 Git 的用户名邮箱和 SSH key，否则提交记录归属不对；· 开启 VS Code 的 Settings Sync，多台机器切换时不用重配。一句话总结：有公网 IP 就走标准 SSH + Remote-SSH，最稳；没有公网 IP 就用 code tunnel 打洞，最省事。两种方式都不需要额外装什么服务端软件。

Skill 的 description 不稳定命中，几乎都是同一个原因：写成了"功能介绍"，而模型需要的是"触发条件"。智能体是根据 description 判断"当前任务要不要加载这个技能"，所以它要的是判断依据，不是产品说明书。一、description 的核心写法：把"什么时候用"写清楚对比一下两种写法：❌ 容易漏触发description: 用于处理前端页面的设计工作。问题：模型不知道"前端页面"包含哪些具体场景，遇到"把这个页面做得好看一点"时不会想到它；"设计工作"太抽象，和实际用户话语没有交集。✅ 命中更稳description: 在需要生成或美化 Web 页面、组件、仪表盘时使用。触发场景包括：新建页面、调整布局与配色、优化响应式表现、把设计稿转成代码、用户反馈界面"不好看/不美观/需要美化"。适用于 HTML/CSS/React/Vue 项目。区别：列了具体动作（新建/调整/转换）+ 列了用户可能说的原话（不好看/需要美化）+ 标了技术范围（HTML/React/Vue）。二、四个具体技巧1. 用"当……时使用"句式开头这是 model card 里最有效的模式。可以直接对标内置技能的写法：· frontend-design："适用于 Web 页面生成和页面美化的场景，当用户需要构建 Web 组件、页面、Web 应用程序时使用此技能"· managing-design-document："智能创建、更新和维护软件项目的技术设计文档"注意两者都包含了"什么时候"和"做什么"，缺一不可。2. 加入用户的口语表达（同义词扩展）用户不会说"进行页面美化"，他会说"太丑了""帮我调一下样式""排得不好看"。把这些口语写进 description，命中率会明显提升。但别堆砌，5~8 个高频表达足够，堆太多反而稀释语义。3. 写明技术边界，排除不该触发的情况加一句 不适用于：后端 API 设计、数据库建模、CI 配置。负样本能有效降低误触发——如果技能总是被错误加载，会挤占上下文，让本该命中时反而效果变差。4. description 要短于 1024 字符，且第一句就给出结论模型的注意力集中在开头，把最关键的场景判断放在第一句。后面再补细节和示例。三、name 也有影响，别忽略· name 只能用小写字母、数字、连字符（如 test-driven-development）；· 用动词或动名词短语：generating-api-docs 比 api-docs-helper 更容易被匹配到"帮我生成接口文档"这类请求；· name 和 description 语义要一致，别一个说"生成"一个说"检查"。四、怎么验证到底稳不稳（这一步最关键）写完不要凭感觉。做一个小小的回归测试：1. 列出 10 条应该触发的典型请求（模仿真实用户说法，别写得太规范）；2. 列出 5 条不该触发的请求（邻近但无关的场景）；3. 逐条在智能体里试，记录"是否加载了技能"；4. 漏触发的补同义词，误触发的补排除条件，迭代 2~3 轮。一般改到 8/10 以上命中就可以定型了。五、还有一种情况不是 description 的问题· 技能没启用：设置 → 技能与规则里，项目级/个人级/内置技能都有开关，默认开启但可能被手动关过；· 技能放错位置：项目级必须在项目根目录的 .codeartsdoer/skills/ 下，个人级在 ~/.codeartsdoer/skills/，放错目录不会被扫描到；· SKILL.md 格式问题：YAML frontmatter 分隔符 --- 不完整、缩进用了 Tab、name 含大写字母，都会导致解析失败被静默跳过；· 上下文太满：技能是按需加载的，如果对话前段已经塞了大量文件上下文，模型可能倾向于不复用工具、直接作答。这种时候新开一个会话反而更稳。排查顺序建议：先确认技能被正确扫描到（设置页能看到）→ 再用上面的 10+5 测试定位是漏触发还是误触发 → 最后才改 description 措辞。跳过前两步直接改文案，很容易改了半天发现是路径放错了。

按"功能清单 + 接口选型"两块展开，最后给一套选型的判断标准。一、B2B 订货系统的功能，可以按三条主线看主线 1：客户采购侧（经销商/门店用什么）· 商品浏览与搜索：按品类、品牌、SKU 编码搜索；只展示该客户有权限购买的商品（区域/等级可售控制）；· 多级价格展示：登录即看到自己的协议价，不是标价；支持阶梯价（买 100 件 vs 1000 件不同价）；· 购物车与下单：常购清单、一键复购、订单模板（B2B 复购率高，这个功能用得多）；· 订单跟踪：下单后能看到审核进度、发货状态、物流单号；· 对账与开票：历史订单对账、账期余额、发票申请；· 移动端：小程序/H5 基本是标配，业务员在客户现场就能下单。主线 2：企业经营侧（总部/业务员用什么）· 客户管理：客户档案、等级、归属业务员、区域划分；· 信用与账期：信用额度、账期天数、超额度自动拦截、逾期提醒。这是 B2B 和 B2C 最大的差别——先控风险再谈体验；· 价格与政策：一客一价、区域价、促销政策、返利规则；· 订单审核流：金额超限、超信用、特殊折扣走审批，支持多级审批；· 业务员业绩：按业务员/区域统计订单额、回款、客户活跃度；· 库存协同：多仓可售库存、库存预占、缺货提示、调拨申请。主线 3：后台支撑（IT 关心的）· 组织与权限（总部—分公司—经销商多级）、数据隔离；· 与 ERP/WMS/财务系统对接；· 操作日志与审计；· 数据导出与备份。二、接口怎么选：先定对象，再定协议1. 常见对接场景与推荐方式· 对接自有 ERP（商品、价格、库存、订单回传）：REST + JSON，由订货系统提供 OpenAPI；如果实时性要求高（库存秒级），考虑消息队列（如 RocketMQ/Kafka）做异步同步；· 对接物流/快递：多数服务商提供 REST 接口，注意电子面单接口通常需要单独申请资质；· 对接支付：企业网银/聚合支付，走服务端回调，不要在客户端验签；· 对接第三方电商平台（如果同时做 B2C）：平台一般提供 SDK，注意各平台的签名算法和限流规则不一样。2. 接口设计的六个硬性要求（拿来当验收清单）① 幂等：订单创建必须支持幂等键（如 clientOrderNo），重复提交返回同一订单，不能生成两单；② 签名鉴权：AK/SK + HMAC 签名，或 OAuth2；不要用固定 token 裸奔；③ 增量同步：商品/价格/库存都支持按 updateTime 增量拉取，几万 SKU 全量同步会拖垮系统；④ 回调可重试：状态变更用 webhook，必须约定重试次数、退避策略、失败告警；⑤ 限流说明：明确 QPS 上限和超限返回码（429），方便上游做退避；⑥ 错误码规范：业务错误和系统错误分开，返回可读的 message 和 traceId，否则线上排查无从下手。3. 三种集成方式的取舍· API 对接（推荐）：解耦、可授权、可限流，是长期方案；· 中间表/文件交换：适合老 ERP 没有 API 的情况，用定时任务读写中间库或 SFTP 传文件，简单但实时性差、难以追溯；· 数据库直连（不推荐）：表结构一变就全线崩，无法做权限隔离，出问题互相甩锅。只在小规模、短期过渡时用。三、选型时最该问供应商的五个问题1. 订单接口支持幂等吗？幂等键是什么字段？2. 商品/库存支持增量同步吗？同步延迟是多少？3. 有没有开放的 OpenAPI 文档和沙箱环境？（没有沙箱的一律慎选）4. 合同到期后，全量数据能不能导出？导出格式是什么？（这条最容易被忽略，换供应商时是致命的）5. 高并发场景的实测数据：日订单 1 万/10 万时的响应时间和限流阈值。四、落地顺序建议先做最小闭环：商品 → 下单 → 审核 → 发货 → 对账。这五步跑通业务就能转起来；营销、返利、多级分销等复杂规则二期再上。存量客户迁移通常是最大工作量，务必双轨运行 2~4 周，把订单量、金额、库存三项对平再切换。

先直接回答"什么样的企业适合"，再说这类系统通常包含哪些模块、接口怎么选，方便你对照自己的业务判断。一、适合上云订货系统的企业画像不是所有企业都适合。下面这几类收益最明显：· 有下游经销商/门店网络：经销商多、层级多（总代—省代—门店），靠电话/微信/Excel 下单，订单容易错、价格容易乱；· SKU 多、价格体系复杂：同一商品对不同客户等级、不同区域、不同促销期有不同价格，人工报价几乎必然出错；· 订单量大且重复：日均订单几百上千，靠人工录入人力成本高、错单率高；· 需要跨区域协同：总部—分公司—仓库分离，需要统一的订单池和库存视图；· 有账期/信用额度管理需求：要先控额度再发货，纯手工台账管不住。不太适合的情况：客户数量少于几十家、订单每周个位数、SKU 少于几十个的小微企业——上一套系统的运维成本会超过收益，用现成的表单工具或轻量 SaaS 更划算。二、B2B 订货系统的核心功能模块1. 商品与价格· 多级价格体系（客户等级价、区域价、协议价、促销价），支持一客一价；· 商品上下架、起订量、最小包装单位、阶梯价；· 可售范围控制（某商品只对某些区域/客户开放）。2. 订单· 购物车式下单、常购清单/一键复购、订单模板；· 订单审核流（金额超限、超信用额度需审批）；· 订单状态机：待审—待发货—已发货—已签收—已完成，支持部分发货、拆单、退换货；· 订单变更留痕（B2B 场景改单很常见，必须可追溯）。3. 库存· 多仓库存、可售库存 vs 实物库存（锁定/占用概念必须有，否则会超卖）；· 库存同步频率和对账机制。4. 客户与信用· 客户档案、等级、归属业务员；· 信用额度、账期、逾期控制（超额度自动拦截下单）。5. 结算与对账· 在线支付、账期结算、预存款；· 对账单生成、发票申请；· 与 ERP/财务系统的凭证对接。6. 营销与运营· 优惠券、满减、搭赠、返利；· 数据看板：客户活跃度、复购率、滞销品、业务员业绩。三、接口怎么选（这是选型时最容易踩坑的部分）1. 先确认对接对象，再选协议· 对接自有 ERP/WMS：优先让订货系统提供标准 API（RESTful + JSON），把主动权握在自己手里；· 对接第三方电商平台/物流：看对方提供什么，通常是 REST + 签名鉴权（AK/SK 或 OAuth2）。2. 关键接口清单（选型时直接问供应商支不支持）· 商品主数据同步（增量 + 全量）· 价格/促销下发· 库存查询与预占· 订单创建/取消/查询（必须支持幂等键，否则网络重试会产生重复订单）· 发货回传（含物流单号）· 对账单/发票3. 四个必须问清楚的技术细节· 幂等性：订单接口有没有幂等键？B2B 金额大，重复下单是灾难性事故；· 回调还是轮询：状态变更用 webhook 回调更实时，但要确认回调失败的重试策略和签名校验方式；· 限流与配额：日订单量上来后会不会被限流，QPS 上限多少；· 数据归属：合同到期后数据能不能全量导出、格式是什么。这条经常被忽略，但换供应商时是致命的。4. 不要做的事· 不要用"数据库直连"做集成——表结构一变更就全线崩，且无法做权限隔离；· 不要只做全量同步，商品几万个时全量同步会拖垮系统，必须支持按更新时间增量拉取。四、落地建议1. 先跑通最小闭环：商品—下单—审核—发货—对账，这五步通了业务就能转；营销、返利等复杂规则二期再上；2. 存量客户迁移是最大工作量：客户档案、历史价格、未结账期，务必在上线前做一轮完整对账；3. 双轨运行 2~4 周：新旧系统并行，确认订单量、金额、库存三项对得上再切；4. 培训到业务员：B2B 订货系统的实际使用者往往是经销商的业务员，不是 IT 部门，培训不到位会导致线下单继续走微信。

只让指定 IP 访问 22 端口，本质是配一条基于源地址的入方向白名单。给一套可直接照抄的配置和几个必须注意的细节。一、最小操作步骤1. 进入 ECS 控制台 → 实例详情 → 安全组 → 配置规则 → 入方向 → 添加规则；2. 字段这样填：· 协议端口：TCP:22（或自定义 TCP + 22）· 源地址：203.0.113.10/32（单个 IP 必须带 /32）· 策略：允许· 优先级：数值小优先，白名单规则给一个较高的优先级（如 1）· 描述：写清楚用途和有效期，例如 ssh-from-office-203.0.113.10-2026Q43. 如需放行一个网段：源地址写 203.0.113.0/24，不要写成 203.0.113.10/24（这种写法会把整段都放开，是常见误配）。4. 如果需要放行多个来源，加多条规则，一条一个 IP，不要图省事合成大网段。二、容易踩的四个坑· 忘了删默认的 0.0.0.0/0 放行 22 的规则。只加白名单不删旧规则等于没配——安全组是多条规则的并集，只要有一条允许就放行。这是最高频的失败原因。· 多安全组叠加。实例绑了多个安全组时，任何一个组里有宽松规则都会生效，逐个检查组。· 把自己锁在门外。远程改配置前，先在控制台用 VNC/CloudShell 登录做一次验证，或临时保留一条当前 IP 的规则，确认新规则生效后再删除。华为云控制台的“远程登录”（VNC）不经过安全组，是可靠的兜底通道。· 只改安全组没改系统防火墙。如果 OS 里开了 firewalld/ufw/iptables，还要同步放行，否则安全组通了系统层又拦一次。三、更稳妥的两种替代方案1. 跳板机 + 安全组引用：把 22 端口只对跳板机所在安全组开放（源地址选“安全组”而不是 CIDR），运维统一从跳板机进。好处是家宽 IP 变化不用改规则，人员离职只改一处。2. SSM/会话管理器类免公网方案：不开公网 22，通过云厂商的会话管理通道登录，彻底消除公网暴露面。适合对合规要求高的场景。四、验证方法· 在允许的 IP 上：nc -zv 公网IP> 22 应显示 succeeded；· 在不允许的 IP 上（可用手机热点验证）：应当超时而非 refused。超时才说明被安全组丢弃；如果返回 Connection refused，说明网络是通的、只是 sshd 没起，这时要去查服务而不是安全组；· 配完刷新控制台规则列表，确认旧规则已删除、新规则状态正常。五、顺手做的加固· sshd 关闭密码登录改用密钥：PasswordAuthentication no；· 关闭 root 直接登录：PermitRootLogin no；· 装 fail2ban 限制暴力破解尝试；· 变更记录留档，白名单规则最好写上到期时间，避免临时放行变成永久敞口。

eCampusCore 设备接入失败，绝大多数不是设备问题，而是网络路径上某一跳把数据拦掉或路由不到。建议按“从设备到平台”的方向逐段定位，每段都有明确的验证手段。第 0 步：先把失败现象分类不同现象指向完全不同的层，先确认属于哪一种：· 设备侧连不上/超时 → 网络可达性或端口问题；· 能连上但握手/TLS 失败 → 证书、时间、协议版本；· 连上也握手成功，但平台侧看不到设备上线 → 鉴权参数或设备标识不匹配；· 设备显示在线但数据不上报 → topic/权限/报文格式。第 1 段：设备到网关（本地网络）· 设备是否拿到 IP、网关、DNS？现场经常是 DHCP 没下发或 IP 冲突；· ping 网关，再 ping 平台接入域名。注意：很多设备固件禁止 ICMP，ping 不通不能直接判定；· 用 telnet 接入域名> 端口> 或 nc -zv 测端口（MQTT 常见 1883/8883，HTTPS 443）。端口不通就是防火墙或安全组；· 检查设备是否配了错误的代理或静态路由，出厂配置里带公司内网代理是很常见的坑。第 2 段：DNS 解析· 在设备所在网段找一台 PC，nslookup 接入域名> 看是否解析到预期地址；· 现场内网 DNS 把域名劫持到内网地址、或返回 NXDOMAIN 的情况非常多；· 设备固件若只支持 IPv4，确认解析结果没有被优先返回 AAAA 记录。第 3 段：云上网络（VPC / 安全组 / NAT）· 安全组：入方向是否放行了设备源 IP 段到接入端口；注意安全组是“并集生效”，多绑了几个安全组时要一起看；· 网络 ACL：子网级 ACL 是第二道门，安全组放通了 ACL 没放通一样不通（且 ACL 无状态，回程要单独放行）；· NAT/公网出口：如果设备通过专线或 VPN 进来，检查对等连接、路由表里是否有到设备网段的路由；· 带宽与连接数：设备量大时，NAT 网关 SNAT 连接数打满也会表现为“时通时不通”。第 4 段：TLS 与时间· 8883 端口 TLS 握手失败，先查设备系统时间——时间偏差超过证书有效期范围会直接握手失败，这是嵌入式设备最高频的原因之一；· 确认设备支持的 TLS 版本（很多老固件只到 TLS 1.0/1.1，平台已禁用）；· 确认 CA 证书是否完整烧录，自签证书链不全会报 unknown ca。第 5 段：鉴权与设备标识· 设备 ID / 密钥 / 产品 ID 是否与平台上注册的一致（多空格、大小写、复制时截断都很常见）；· 同一设备 ID 被重复注册或重复连接，平台通常会踢掉前一个连接，表现为“反复上下线”；· 检查平台侧的设备状态与接入日志，平台日志里一般会写明拒绝原因（认证失败/配额超限/协议不支持）。推荐的排查顺序先在设备同网段用一台 PC 模拟设备（mosquitto_pub 或 curl）走一遍同样的地址和凭据：· PC 能通、设备不通 → 问题在设备本身（固件、证书、时间、DNS）；· PC 也不通 → 问题在网络或平台侧，继续按第 1~3 段查。这一步能把排查范围直接砍掉一半，比在设备上盲试高效得多。