403 AccessDenied 基本只看四层，按这个顺序排查，五分钟能定位。 第一层，先确认你用的是哪个域名。对象域名是 桶名.obs.区域.myhuaweicloud.com/对象键，静态网站域名是 桶名.obs-website.区域.myhuaweicloud.com。两者不是同一套鉴权：前者走对象读权限，后者还要求开启静态网站托管并配置首页和错误文档。如果你复制的是静态网站域名但没开托管，必然 403。 第二层，对象本身是不是公共读。上传默认继承桶的默认 ACL，多数情况是 private。用 obsutil cp 本地文件 obs://桶名/对象 --acl=public-read，或者在控制台进对象 → 权限 → 公共读。 第三层，桶策略有没有放行 GetObject。对象 ACL 设成公共读、但桶策略里有一条 Deny，照样被挡。桶策略的 Deny 优先级高于对象 ACL，这一层不看会白折腾。 第四层，也是最常见的：桶的「阻止公共访问」开着。这个开关会覆盖前面两层。即使对象是公共读、桶策略也放行了，匿名请求还是 403。控制台路径是 桶 → 权限控制 → 阻止公共访问，先关掉再测。 四层都过了还 403，再查两件事：一是请求头里带没带 Referer，防盗链规则会拦；二是对象是不是归档或冷归档存储类别，这类需要先恢复才能读。 一个快速定位技巧：把对象 URL 直接贴到无痕窗口打开。如果无痕 403、登录控制台能预览，说明是匿名访问权限问题，锁定在第二到第四层；如果无痕也能开、只是你自己程序里 403，那问题在请求头或签名，不在桶权限。 

这个 ID 不在页面上，得从展览馆自己的开放接口拿 先说结论：作品展览馆的活动 ID **不是**大赛平台 `competition/information/xxx` 后面那串数字，两者不通用。拿大赛活动 ID 去提交作品，接口会直接返回「活动不存在」。 正确取法 ```GET Header: X-Tmp-Ak / X-Tmp-Sk / X-Security-Token   （STS 临时凭证）``` 返回的 `data.items[]` 里，`id` 字段就是提交作品时 `trainingCampId` 要填的值。 筛选有两个条件： `status` 必须是 `published`- `isSchoolLinked=false` —— 布道活动、校赛这类都带学校绑定，个人开发者投不进去我实测当天 20 个活动里，符合条件的只有「闯关活动」和「福建区域赛」。 提交接口 ```POST .../open-api-public/v1/gallery/works  trainingCampId / workName / introduction / image / detail / gitUrl / gitBranch``` 两个容易翻车的点：`introduction` 必须 15~50 字符，超了直接拒；`gitUrl` 必须 `https://` 开头、`.git` 结尾，而且分支要真实存在（服务端会 `git ls-remote` 校验）。 STS 怎么来 AK/SK → IAM 查 Domain ID → AssumeAgency `iam:::agency:SELF_VERIFY`。 如果报 `iam:agencies:list` 无权限，说明用的是 IAM 子用户（默认没有委托权限），需要主账号在控制台先建一个名为 `SELF_VERIFY` 的委托，委托对象选自己账号。 顺带提一句：展览馆发布是**月度任务**，当月领过一次积分后再发布不会重复给分。 

灰度这件事，建议拆成两个独立问题：流量怎么分（路径），和什么条件下继续放量（判定）。混在一起做，出问题的时候说不清是谁的锅。一、流量分配的三条路径。1）入口层权重：负载均衡或 Ingress 上按实例权重分，最简单，但只能做到「一部分请求走新版本」，不能指定是谁。适合第一阶段探活。2）按特征圈人：用 Header、Cookie 或用户 ID 哈希做路由，把内部员工、白名单用户、某个地区的流量导到新版本。要注意哈希要稳定（用 userid 取模而不是随机），否则同一个用户体验会来回跳版本，问题复现不了。3）应用层功能开关：代码里埋 flag，配置中心下发。这是唯一能做到秒级回滚的方式，也是唯一能按租户维度精确控制的。上线顺序建议是：先埋 flag 默认关，再开权重，最后按特征放量。二、判定要看什么。只看错误率不够。至少四组：错误率、P95/P99 延迟、下游依赖的错误率、业务指标（下单成功率、支付转化）。而且要和同一时间窗的对照组比，只看绝对值的灰度很容易被流量波动骗过去。放量节奏按 1% → 5% → 25% → 50% → 100%，每一步留够一个业务周期的观察窗口，别用十分钟的样本下结论。三、比灰度本身更容易翻车的前提。兼容性没做好，灰度就是给自己挖坑：新版本写的字段老版本读不了、消息格式加字段导致旧消费者反序列化失败、缓存里新旧格式混存。做法是接口只增不改、字段可空、消息带版本号、缓存 key 加版本前缀。数据库变更走「先加列后删列」两阶段，否则回滚时数据已经写进去了，退不回去。四、几个常见坑。会话粘性导致灰度样本全落在同一批重用户上，指标失真；只灰度单实例，CPU 和连接池压力被放大，误判成性能退化；配置中心的开关和代码版本不同步，出现「代码已回滚但开关还开着」；灰度环境和生产共用数据库，脏数据无法回收。五、落地建议。先做最小闭环：一个 flag + 一个对比看板 + 一条回滚脚本，跑通一次真实灰度再扩。自动回滚的阈值要提前定好并演练一次，出事的时候人是想不起来现算的。最后，灰度不是发布流程的附属品，它本身要有一套演练机制，否则第一次真的用上时就是生产事故。

锁这件事，先把语义拆开：互斥、防死锁、可重入、失效安全。前三个决定能不能用，最后一个决定出事时谁来兜底。Redis 方案的两个细节。加锁必须是 SET key token NX PX 一条命令完成，token 用随机值；释放用 Lua 脚本先比对 token 再删，避免 A 的锁超时后 B 拿到，A 醒来把 B 的锁删掉。这两点已经能挡掉大部分踩坑。但 Redis 主从是异步复制。主节点写完 NX 就返回成功，宕机切到从节点时这把锁可能根本不存在，两个客户端同时持锁。所以单实例 Redis 锁的强度是「大概率互斥」。真要强一些，光靠 Redlock 不够稳——它依赖各节点时钟和进程不长时间停顿，GC 一次就可能越界。更实际的做法是 fencing token。锁服务每次授予锁时返回一个单调递增的序号，客户端带着序号去写资源，存储层拒绝比已见序号小的写请求。这样即使两个客户端同时自认为持锁，后到的那个写也会被拒绝，互斥性由存储层保证，而不是由锁的可用性保证。etcd 的 revision、ZooKeeper 的 zxid 天然带这个性质，这也是它们在强一致场景更受青睐的原因。其余几种方案怎么选。ZooKeeper / etcd：临时节点或 lease，客户端断连自动释放，配合 revision 有 fencing 语义，代价是吞吐低、依赖额外集群。数据库唯一索引或 select for update：实现最简单，适合低并发、已经在事务里做的事，注意锁等待超时和行锁升级。几个高频坑：锁超时短于业务执行时间导致提前释放，用看门狗续期而不是简单调大过期时间；锁内做远程调用或重试，把持锁时间拉长；释放写在 try 里而不是 finally 里；锁粒度按业务拆细，不要一把大锁锁住整个流程；把锁当成幂等替代品，重试时仍会重复执行。结论：能容忍极偶发双写（例如缓存重建、报表任务）用 Redis 锁就够；涉及金额、库存这类不能双写的场景，要么上带 fencing token 的锁，要么干脆在存储层做版本校验和唯一约束——锁只是降低冲突概率，不是正确性的最终防线。

几个要点，能直接照做： 1）一定要显式给 timeout。requests 默认不超时，对端不返回就一直挂住。用元组区分连接和读取：(connect=3s, read=按这个接口 P99 的 1.5~2 倍)。连接超时要短，读超时要贴近业务真实耗时。 2）先分清哪些错能重试。连接类错误（ConnectionError、ConnectTimeout）重试收益最高；ReadTimeout 要看请求是否幂等——GET/HEAD/PUT/DELETE 可以重试，POST 重试可能重复下单/重复扣款，必须带幂等键（Idempotency-Key）或在重试前先查询确认结果。 3）别手写 for 循环，用 urllib3 的 Retry 挂到 HTTPAdapter 上，参数比循环清楚：total 控制总次数，connect/read 分开计数，backoff_factor 做指数退避，allowed_methods 只放幂等方法，status_forcelist 限定 429/500/502/503/504，respect_retry_after_header 让服务端的 Retry-After 生效。 4）退避要加抖动。固定间隔重试容易在服务端恢复的瞬间形成二次洪峰，指数退避 + 随机抖动（full jitter）能把请求摊开。 5）设总预算。单次请求的重试总耗时要有上限（比如 8s），超过就快速失败，把错误抛给上层。否则重试会把调用线程堆满，故障从一个下游扩散成整个服务超时。 6）复用 Session 并配好连接池（pool_maxsize 与并发数匹配），否则每次重试都新建连接，TLS 握手成本比请求本身还高。 7）埋指标：记录 attempt 次数、每次耗时、最终状态码。重试率突然上升通常是下游劣化的最早信号，比错误率更早暴露问题。 一句话：超时要分层、重试要幂等、退避要抖动、总时长要有预算。

从工程视角补一个更好落地的判断方法：先按「谁来控制流程」分档，再看工具层。 1）人在环内、每步确认。CodeArts 代码智能体、Cursor、通义灵码这类，适合需求模糊、需要边看边改的场景，出错成本最低。 2）固定流程里嵌模型节点。把 LLM 当成流程里的一个算子，用可视化编排或自己写任务图，适合客服分流、日报生成、数据清洗——要求可复现、可回滚，不能让模型自由发挥。 3）长链路自主执行。给一个目标，自己规划多步并调用工具，适合调研和批量处理；但失败率随步数快速上升，必须设检查点和人工兜底。 选型先回答三个问题：任务能否拆成固定步骤（能→第 2 档）；失败一次的代价多大（大→第 1 档）；输入是否高度不确定（是→第 3 档）。 还有个常被忽略的点：真正的成本不在模型，在工具层。把内部系统的查询、变更、通知封装成有清晰 schema、幂等、有权限边界的函数。工具层做好，上面换哪家 agent 都不心疼；工具层没做好，模型再强也只能靠猜。 最后，先量基线。没有人工耗时和错误率的基线，任何「效率提升」都无法验证。