楼主把两条路线的分工讲得很清楚了，我补充一份落地时真正用来做决策的清单，帮后来人少走弯路。一、先按三个问题选路线，不要先看价格1. 载体要不要“一直在线”？纸质文件、光盘、U盘这类平时放在柜里、只在借还和盘点时才动的小件，用超高频无源 RFID 就够了：批量清点、出入登记、周期盘点是它的主场。2. 离位要不要“马上知道”？涉密便携设备、移动柜位这类一旦离开规定区域就必须立刻告警的载体，才需要有源 2.4G+125K 双频：在位监测、离位告警、轨迹留痕是它的主场。3. 载体数量有多大？几百件以下、预算有限时，先上无源做全量台账；上千件、且其中只有一小部分是高价值移动设备时，无源全量加双频重点覆盖，混合部署最划算。二、混合部署的边界建议按载体分区而不是按部门分区：同一间办公室里，文件柜里的纸质文件走无源通道门和手持盘点，桌上的涉密笔记本走双频在位监测。两套标签、两套读写设备、同一套台账系统，数据口径统一在载体编号上，不要各建一套台账，否则对账永远对不上。三、现场最容易踩的三个坑1. 金属柜：普通无源标签贴进金属文件柜读距会明显缩短，务必换抗金属标签，并实测贴附位置和天线角度，不要只看实验室数据。2. 双频点位：125K 低频点位要布在门禁、柜口这些必经点位上，2.4G 覆盖要避开金属柜体遮挡，部署后逐点做“带标签走一遍”的实测，再验收。3. 电池与盘点：双频标签要把低电量预警接进日常巡检流程，定好更换周期和责任人；无源标签也要定期抽检读取率，标签损坏、脱落要能及时补发。四、建议的上线顺序先建台账、再上设备、最后接告警：第一步把载体编号规则和现有二维码台账打通；第二步小批量试点，验证读取率和告警准确率；第三步全量推广并把借还、销毁、离位告警写进管理制度。技术选型只占一半，流程和责任人到位，系统才算真正管起来。

先说结论：你看到的“文字”只是文档的最表层，真正决定排版的是藏在文字背后的三层东西——段落样式、直接格式化，以及段落标记和分节符里保存的分页规则。直接粘贴默认是“保留源格式”，会把源文档的这三层东西一起带进目标文件，而这些东西在页面上是看不见的，所以冲突也是“肉眼看不到”的。 一、为什么会冲突：三个看不见的层级 第一，段落样式与字符样式。Word 里每一段文字都有一个段落样式，比如“正文”“标题 1”，样式本身定义了字体、字号、行距、段前段后间距和缩进。两份报告可能都有一个叫“正文”的样式，但 A 文档的“正文”行距是 1.15 倍、段后 6 磅，B 文档的“正文”是单倍行距、段后 0 磅。粘贴后，目标文件里只能存在一个“正文”样式定义，先进入的定义获胜，后粘贴进来的段落会被强制套用目标文件的“正文”，于是同一段文字换了行距、段落被撑开或挤紧，看起来却“什么都没改”。 第二，直接格式化覆盖在样式之上。有人在源文档里手动把某段字号改成 14 磅、加粗、改颜色，这些“直接格式化”会跟着内容一起粘贴过来，优先级高于段落样式。所以合并后的文档里，同样是“正文”样式的段落，有的 12 磅、有的 14 磅，有的行距 1.0、有的 1.5，眼睛很难逐段发现。 第三，段落标记与分节符里藏着分页规则。每个段落末尾的段落标记保存了“与下段同页”“段中不分页”“段前分页”等属性；文档里还可能有分节符，节里保存着页边距、纸张方向、页眉页脚和页码格式。粘贴会把这些属性也带过来，于是出现帖子里说的现象：一段粘贴后正常，另一段整块被挤到下一页——不是文字太多，而是那段设置了“与下段同页”或“段前分页”；手工编号和自动列表混用时，插入新段落还会让序号跳变。 二、定位问题：先让看不见的东西现形 不要直接在原文件上改，先另存一个副本再操作。打开“开始 → 显示/隐藏编辑标记”，把段落标记、空格点、制表位箭头、分页符和分节符都显示出来；再打开“样式”窗格，逐段点一点，看看每段实际套用的是哪个样式、样式定义是什么。异常段落通常有三个特征：样式名相同但显示效果不同；段落标记上带有“与下段同页”等小标记；列表段落的编号是手工敲进去的数字，而不是自动编号。把这些段落挑出来，问题范围就缩小到几段之内。 三、正确的合并步骤 第一步，先在副本里统一“地基”：确认目标文件的标题 1、标题 2、正文样式定义，记下行距、字号、段前段后间距。 第二步，粘贴时用“只保留文本”：在目标文件里粘贴后点粘贴选项，选“只保留文本”，或用“开始 → 粘贴 → 选择性粘贴 → 无格式文本”。这一步会丢掉源格式，只留下纯文字，再统一套用目标文件的样式，冲突从根上消失。缺点是表格、公式、带题注的图片会丢失格式，所以这些内容要单独处理，不要一刀切。 第三步，逐段套用样式：正文段落统一套“正文”，标题按层级套“标题 1、标题 2、标题 3”，不要用直接改字号的方式“冒充”标题，否则目录无法生成。 第四步，列表改用自动编号：把手工敲的“1. 2. 3.”删掉，用“多级列表”重新编号，插入新段落时序号才不会跳变。 第五步，表格、题注、交叉引用单独检查：表格粘贴后检查列宽与“允许跨页断行”；图片题注重新用“插入题注”生成；引用了标题或页码的交叉引用要全选后按 F9 更新域。 第六步，最后通查三件事：更新目录（引用 → 更新目录 → 更新整个目录），检查页眉页脚和页码是否被分节符带偏，通读一遍确认没有段落被“与下段同页”挤到下一页。 四、怎么预防下一次 把目标样式写进团队模板并共享：标题、正文、表格、题注各用什么样式、行距多少，都定死；写报告时只用样式、不手动改字号行距；Word 的“文件 → 选项 → 高级 → 剪切、复制和粘贴”里，把“从其他程序粘贴”默认改成“仅保留文本”，能省掉大部分合并时的返工。WPS 和 Word 的样式名、默认模板不完全一样，跨软件合并前最好先在一方里统一样式再粘贴。 一句话总结：直接粘贴带过来的不是文字，而是文字背后的样式定义和分页规则；看不见它们，冲突就无从下手。先显示编辑标记找到异常段落，再用“只保留文本 + 重新套用目标样式”的流程合并，最后更新目录和域，问题基本都能解决。

1楼把“一张表、一个动作、逐项验收”的拆法讲得很全了，我补充一个1楼没有展开、但实际最容易写错的点：先分清推近到底是 dolly 还是 zoom，再决定环绕怎么做，两个动作的“物理含义”不同，混在一起写，工具就容易各做各的。一、推近有两种，提示词里要写明是哪一种推近不是一个动作，而是两种完全不同的相机变化：1. Dolly in（机位前移）：相机真的向主体靠近，透视会变——主体变大，背景相对主体移动，近大远小的感觉更明显。2. Zoom in（变焦拉近）：机位不动，只改焦距，透视基本不变，画面像是把远处“裁大”，背景会被压缩，主体和背景的相对位置几乎不动。很多失败的镜头就是提示词只写“推近”，工具随机选了一种，结果和想要的完全相反。写法上直接写死：“相机向前移动推近（dolly in），不要只变焦”或“机位固定，只做变焦推近（zoom in）”。二、环绕要先定圆心和半径，推近要先定终点距离环绕（orbit）的前提是圆心和半径不变：相机以主体为中心，距离保持不变，只改变角度，例如“以设备为圆心，距离不变，从正面0度匀速移到侧面45度”。如果同时还在推近，半径就在变，工具很难同时满足“距离不变”和“距离变小”，结果往往是主体漂移或背景跳变。可行的组合只有两种：1. 时间分段：前2/3时间做推近（角度不变），后1/3时间做环绕（距离不变），写成“0–3秒推近，3–6秒环绕”，不要写“同时”。2. 一镜复合时用关键帧：首帧写景别和角度，中帧写推近一半、环绕约20度，尾帧写最终景别和角度，三帧都写清楚，让工具按帧拟合。三、给一个能直接套用的写法以讲解视频里的设备为例：“首帧：正面全景，设备完整在画面内。0–3秒，相机直线前移推近（dolly in），角度保持正面0度不变，终止画面为中景，控制面板占画面约60%。3–6秒，相机以设备为圆心、距离不变，从正面0度匀速环绕到侧面45度，终止画面为侧面接口与线缆走向可见。背景保持稳定，主体位置不移动。”时间、角度、占比都写成数字，验收时才能逐项对照：推近段主体是否变大、环绕段背景是否反向移动、终止画面是否达到要求。四、工具不支持复合运镜时的退化方案如果生成工具一次只能做一个运镜，不要硬写复合镜头，改用切镜模拟：推近做一个主体特写镜头，环绕改成三个静态角度的短镜头（0度、30度、60度）依次切换，再加静态标注说明接口位置。对讲解视频来说，讲清部件关系比“一个长镜头拍完”更重要，也更容易验收。五、出现漂移先查哪一项出现主体漂移、背景旋转方向反了、透视跳变时，按这个顺序查：先确认提示词里有没有同时写“距离不变”和“推近”这种互相矛盾的要求；再确认是 dolly 还是 zoom 写错了；最后才调速度和角度。一次只改一项，改完重新生成对照，否则不知道是哪一项引起的。

前面两位把「先小后大、按监控调配」讲得很全了，我补充一个容易被忽略的角度：很多时候瓶颈不在单台规格，而在架构能不能横向扩展。一、先判断这台 ECS 需不需要「变大」如果业务是无状态 Web 服务，2 台 2 核 4G + 负载均衡，往往比 1 台 4 核 8G 更划算：单台故障不影响业务，还能按量增减。反过来，单机 MySQL、Redis 这类有状态服务才值得认真挑单台规格，优先保证内存和磁盘 IOPS，CPU 反而可以先放一放。二、压测要看 P95 和错误率，不只看平均利用率上线前用 wrk 或 ApacheBench 按真实峰值并发压一轮，重点看三个数：P95/P99 延迟、错误率、CPU steal 时间。平均利用率 40% 但 P99 延迟抖动大，说明瓶颈可能在磁盘 IOPS 或带宽，而不是核数；这时升核数是白花钱，应该先看云监控里的磁盘读写延迟和网络情况。三、容易漏算的三笔钱公网带宽（按量计费的突发流量）、云硬盘 IOPS 上限（普通 IO 盘跑数据库容易先顶满），以及闲置的弹性 IP、快照和备份存储。选型时把系统盘和数据盘分开，数据库单独挂一块高 IO 盘，比整台升配便宜。四、给选型留好「后悔药」华为云 ECS 变更规格一般需要停机操作，生产环境要提前留变更窗口；也可以先用弹性伸缩把波动部分交给自动扩缩容，基线部分再包年包月。选型不是一锤子买卖：先定一个能横向扩展的架构，再用压测数据定单台规格，最后按季度复盘利用率调配，这样成本和性能才长期平衡。

前面几位已经把权限、计费、碎片、版本控制、403/404 这些高频坑说得很全了，我补一个还没人提过的：更新了同名对象，浏览器里看到的还是旧内容——缓存坑。 现象：把图片或网页文件重新上传到 OBS（同名覆盖），在控制台看对象已经是新文件了，但浏览器打开链接还是旧图，Ctrl+F5 刷新几次才变过来；如果前面接了 CDN，旧内容可能要等更久。 原因有三层：第一，浏览器缓存了旧对象；第二，OBS 对象自带 Cache-Control/Expires 元数据，上传时没改，默认值可能让浏览器按旧的缓存时间来取；第三，CDN 节点缓存了旧版本，源站更新了，边缘节点还没回源。 怎么处理：1. 先分清是“没传上去”还是“缓存没更新”：在控制台确认对象的最后修改时间和大小变了，再用无痕窗口或在链接后面加一个随机参数（例如 ?t=20261110）打开一次——如果带参数能看到新内容，基本就是缓存问题。2. 经常更新的文件，上传时就把 Cache-Control 设短一点，例如 max-age=300，或直接设 no-cache；不常变的文件可以设长一点，更新时改文件名或加版本号（logo-v2.png），比等缓存过期可靠。3. 走了 CDN 的，更新后要在 CDN 控制台做缓存刷新（按 URL 刷新），只刷新改过的那几个文件，别全站刷新。4. 做静态网站托管时，首页 index.html 这类经常改的文件建议单独设短缓存，图片、JS、CSS 这类带版本号的文件可以设长缓存。 一句话：上传成功不等于用户立刻看到新内容，更新同名对象后，先查缓存、再查文件本身，别一上来就怀疑上传失败或权限出问题。

先给结论：规格没有“一次选对”的最优解，平衡成本与性能靠的是“选对族、从小起步、用数据定型、用弹性削峰”四件事。下面是我常用的做法： 一、先按业务画像选规格族，再选大小 不同负载的瓶颈完全不同，先按瓶颈定“族”，再在族里定大小，同样预算性能差很多： Web 服务、API、微服务：瓶颈通常在 CPU 和并发，选通用型（常见的 1:2 配比，如 2 核 4G、4 核 8G 起步）。数据库、缓存、大堆 JVM 应用：瓶颈在内存，选内存型（1:8 配比），否则容易出现 CPU 很空、但频繁 GC、响应抖动。视频转码、AI 推理、离线计算：瓶颈在算力，选计算型或 GPU 型。 二、从小规格起步，用 1 到 2 周真实流量定型 新业务没有历史数据时，先用最小够用的规格上线（比如 2 核 4G 通用型），跑 1 到 2 周真实流量，看云监控里 CPU、内存、内网带宽的 P95 值。规格要能覆盖 P95 并留 30% 左右余量，而不是覆盖偶发峰值，峰值交给弹性伸缩扛。常见误区是按峰值翻倍买，最后常年利用率不到 20%，钱白花了。 三、计费方式和业务节奏要匹配，这是省钱的大头 长期 24 小时在线的基线容量用包年包月，比全按量便宜不少；有明显波峰波谷的业务（白天高、夜间低）用弹性伸缩组，设“CPU 均值超 60% 加一台、低于 25% 减一台”，平时只付最小规模的钱；能随时中断的离线任务（压测、批量转码）可以考虑竞价实例或定时开关机。只用一种计费方式，往往是贵的根源。 四、验收和复盘要有数字 调完规格后看两个指标：CPU 利用率稳定在 40% 到 60% 区间、应用 P95 响应时间没有明显变差，说明规格合适。之后每月复盘一次：CPU、内存 P95 长期低于 20% 的直接降配；长期高于 70% 或已出现排队时延的，先横向加实例再考虑升配；同时清理闲置资源，没挂载的云硬盘、没绑实例的弹性公网 IP、没用的快照都会持续计费。 一句话总结：按瓶颈选规格族、用 P95 定大小、用计费组合和弹性策略削峰、用月度复盘持续纠偏，成本和性能就不需要二选一。

新手用 OBS，我踩过也帮别人排过，补充几个前面楼层提得少、但一上线就容易出问题的点：一、对象元数据 Content-Type 不对，浏览器行为就变了上传图片、PDF 时如果 Content-Type 被写成 application/octet-stream，浏览器会直接下载而不是在线预览。上传时按文件类型设置正确的 Content-Type；已经传错的可以在控制台修改对象元数据，不用重新上传。二、做网站或图片直链，别只开桶，还要配 CORS 和防盗链前端跨域读对象要配 CORS 规则（来源、方法、请求头缺一不可）；公开的图片、视频资源建议开防盗链（Referer 白名单），否则链接一旦被盗用，外网流出流量费会悄悄涨。三、加密和合规：先确认再传敏感数据OBS 支持服务端加密（SSE-KMS / SSE-OBS），存身份证、合同类文件建议开启；另外注意桶的区域：数据一旦写入，跨区域迁移要靠跨区域复制或重新上传，建桶前先定好区域。四、上手建议：先用 obsutil 走一遍最小闭环obsutil ls obs://桶名 确认对象真的传上去了；obsutil cp 本地文件上传、下载各做一次；再用带过期时间的临时签名 URL 验证别人能下载、过期后打不开。走通这三步，再接 SDK 或控制台操作。五、费用上最容易被忽略的两项一是请求次数（PUT/GET/LIST 都计次，程序里高频 LIST 桶会很贵）；二是外网流出流量（走公网下载、CDN 回源失败反复拉取都会产生）。控制台「用量统计」里能按天看到这两项，上线第一周每天看一次。一句话总结：先拿测试桶把「上传-下载-签名 URL-删除」走通，再看用量统计确认没有版本残留和碎片，最后才上生产数据。

补充一个前面几位没有展开的角度：50MB 大 Key 的伤害不只在 HGETALL 执行那一刻，持久化和主从复制时会再放大一次。一、持久化和复制会把 50MB 再搬运几遍RDB 保存（bgsave）和 AOF 重写（bgrewriteaof）都要把这个 50MB 的 Hash 整体序列化写盘；主从全量同步时也要整体传给从节点，故障切换后新主加载 RDB 也要重新解析它。也就是说，这个 Key 平时只影响一次 HGETALL，但一到备份、重写、主从切换这些时刻，就会变成几十 MB 的一次性大操作，拉长恢复时间。所以大 Key 的治理优先级不能只看日常命令耗时，还要看它对备份窗口和故障恢复的影响。二、客户端那一侧也要算账HGETALL 返回 50MB，服务端序列化、网络传输、客户端反序列化三段都要花时间。客户端拿到 50MB 再做解析或对象映射，内存峰值和 GC 都会抖。只读个别字段时直接用 HMGET 取需要的字段，不要把整个 Hash 拉回来再过滤。三、如果它同时还是热 Key活动配置类 Key 经常既大又热：高频读又全量读。拆分之后建议再叠加一层应用本地缓存（带版本号，配置变更时推新版本），把高频读挡在本地，Redis 只做版本校验和兜底，这样拆分和缓存两步加起来，P99 才能真正打下来。验收时除了看 MEMORY USAGE、HLEN 和慢查询，也对照一次 bgsave 或主从同步的耗时有没有回落，这一项回落了，才算把大 Key 的连带影响清干净。

前面几位把排查顺序讲得很全了，我补充两个容易被忽略、但能直接定性的点。一、别只看快照，要看连接数的走势。用一个已有连接每 10 秒采一次 Threads_connected，连采 5 分钟看曲线：一直单调上升、基本不回落，大概率是泄漏或事务没归还；冲到上限后快速回落、反复出现，是突发流量或定时任务；卡在上限附近不动、Threads_running 也高，是慢 SQL 或锁把连接拖住了。只看一个时间点的数字，这三种情况长得一模一样。二、区分“数据库连接满了”和“应用连接池满了”。应用报错时，先看连接池指标：HikariCP 的 threadsAwaitingConnection 持续大于 0、连接获取超时，说明应用侧池子已经在排队，哪怕数据库还有余量，业务也会报错。这时先查池子大小、获取超时和重试逻辑，别急着动数据库。最后补充一个现场留证的小习惯：动手 KILL 之前，先把 processlist 完整导出一份存下来，之后复盘、找泄漏代码都要靠它；杀完就查不到了。

先把差额算出来，再按差额分流。你已经试过 lsof 没发现明显的，说明大概率不是“已删未释放”这一种，重点查下面几处。 一、先算差额，确认查的是同一块盘假设满的是 /data，换成 df 显示的实际挂载点：df -B1 /datasudo du -x -B1 --max-depth=1 /data用字节对比 df 的 Used 和 du 最后一行的总计，差额就是要找的“隐形占用”。注意三点：du 要加 -x 限定在同一文件系统；要用 sudo 跑，普通用户权限不足被跳过的目录最容易漏；不要用 /data/*，会漏掉隐藏目录。 二、lsof 没发现，换两种姿势再确认一次普通用户跑 lsof 只能看到自己的进程，系统服务持有的已删文件看不到；输出不排序时大文件也很容易被淹没：sudo lsof +L1 | sort -k7 -rn | head -20sudo find /proc/[0-9]*/fd -lname '* (deleted)' -printf '%p -> %l\n' 2>/dev/null | head -20如果确认是某个进程持有，处理不一定要重启：用 : > /proc//fd/ 把内容截断就能立刻释放空间；日志类文件事后加上 logrotate，避免以后直接 rm 正在写的文件。 三、最容易漏的第二种：挂载点把旧数据盖住了典型场景：先往 /data 写了几十 GB，后来又把一块云硬盘挂到 /data 上，旧文件还占着父文件系统的空间，但 du 走的是挂载后的目录树，看不见。验证不用 umount：sudo mkdir -p /mnt/rootviewsudo mount --bind / /mnt/rootviewsudo du -sh /mnt/rootview/data如果这里看到 du 之前统计不到的几十 GB，就是它，确认后把遮挡的数据移走或删除即可。也可以先用 findmnt -R / 看完整挂载树找可疑挂载点。 四、再看三处“藏在目录树里不起眼”的占用1. systemd journal：journalctl --disk-usage 看一眼，/var/log/journal 经常攒到几个 GB；应急用 sudo journalctl --vacuum-size=200M --vacuum-time=7d 释放，根治是在 journald.conf 里设 SystemMaxUse 上限。2. Docker 容器日志：跑了容器的话，单个容器的 *-json.log 没有轮转能涨到几十 GB，docker system df 看不到它，要直接看 sudo du -sh /var/lib/docker/containers/*；应急用 truncate -s 0 截断对应日志文件，根治是在 daemon.json 里配 max-size/max-file 日志轮转。3. /tmp、/var/crash、coredump：sudo du -sh /tmp /var/tmp /var/crash，coredumpctl list 看看有没有堆积。 五、最后区分另外两种“满”df -i 看 inode 使用率：海量小文件会把 inode 吃光，表现也是 df 满、du 找不到大文件，这时要找的是小文件密集的目录，不是大文件。ext4 预留块：ext4 默认给 root 预留 5%，用 tune2fs -l /dev/xxx | grep Reserved 确认；数据盘可以适当调低预留比例，系统盘不建议动。 按“算差额 → 再查一次已删文件 → 挂载遮挡 → journal/容器日志/tmp → inode/预留块”这个顺序跑一遍，差额基本都能对上。建议贴一下 df -B1、df -i 和 du -x 的结果，以及文件系统类型，能更快定位到某一项。