云原生可移植性不是「写了 Dockerfile 就能搬」，真正的障碍在托管服务依赖和隐式平台假设。按层次拆开看：一、容器层（最容易做到）· 镜像用多架构构建（docker buildx build --platform linux/amd64,linux/arm64），否则搬到鲲鹏/ARM 集群直接跑不起来；· 基础镜像选 distroless 或 alpine，别依赖宿主机的 glibc 版本；· 镜像不带配置文件和环境特定路径，全部走环境变量或挂载。二、编排层（K8s 是事实标准，但别用厂商扩展）· 只用标准 API：Deployment / Service / Ingress / ConfigMap / Secret / HPA。厂商的 CRD（比如某云的弹性伸缩自定义资源）一用就绑死；· Ingress 用标准 ingressClassName，别写死某个负载均衡器的注解；· 存储用 StorageClass 抽象，PVC 声明容量和访问模式，不写具体云盘 ID；· 别依赖特定节点标签/污点做调度，用 nodeSelector 的通用标签（arch、gpu）。三、配置与状态（12-Factor 的核心）· 配置外置：ConfigMap/Secret 或配置中心，代码里不允许出现 endpoint、AK/SK；· 无状态化：会话存 Redis，文件存对象存储，本地磁盘只做临时缓存；· 优雅停机：处理 SIGTERM、等待在途请求、从注册中心摘除，否则滚动更新必掉请求；· 健康检查分离 liveness 与 readiness，别让启动慢的服务被反复重启。四、最硬的骨头：托管服务用了云厂商的 RDS、消息队列、对象存储、函数计算，迁移成本就上来了。应对策略：· 数据访问层加一层抽象（Repository 模式），SQL 只用标准语法，别用厂商私有函数/扩展；· 消息队列用标准协议（AMQP/MQTT/Kafka 协议），别用私有 SDK 的专有能力；· 对象存储走 S3 兼容接口（华为云 OBS、阿里 OSS、MinIO 都支持），代码里用 S3 SDK 而不是各家的原生 SDK；· 认证鉴权走 OIDC/OAuth2 标准，别把厂商 IAM 的角色模型写进业务逻辑。五、可观测性日志打 stdout（结构化 JSON），指标用 Prometheus 格式暴露 /metrics，链路用 OpenTelemetry SDK。这三样标准化之后，换监控后端只是改配置。六、验证方式可移植性必须被验证，否则只是纸面承诺。做法：CI 里加一步「在 kind/k3d 起的干净集群上跑一遍完整部署 + 冒烟测试」，任何隐式依赖（缺 ConfigMap、写死地址、依赖特定存储类）都会在这一步暴露。这个检查成本很低，收益极高。最后一句实话：100% 可移植是不划算的目标。合理做法是「核心业务逻辑与数据可移植，非核心的运维能力（监控、日志、CDN）允许绑定」，把迁移成本控制在「重写部署清单」的量级，而不是「重写应用」。

「agent」这个词现在被用得很泛，实际分成四类，选型先看你属于哪一类：1. 编码类（IDE 内 agent）Cursor、Claude Code、GitHub Copilot、通义灵码、华为云码道 CodeArts Snap、Trae。这类是当前落地最实的——有明确的文件读写和终端执行环境，反馈闭环短。日常写业务代码、改 bug、写测试，效率提升最直接。选型看两点：模型能力（长上下文与工具调用稳定性）和是否支持本地仓库索引。2. 通用自主 agent（浏览器/桌面操作）Manus、扣子空间、各类 computer-use 产品。适合「帮我查资料整理成表」「跑一遍网站流程」这类跨系统的模糊任务。目前瓶颈在稳定性：长链路任务的成功率还不高，适合人盯着用，不适合无人值守。3. 企业工作流编排（最容易被低估）Dify、Coze、n8n、FastGPT。严格说不是「自主 agent」，而是把 LLM 节点嵌进确定性流程。优势是可观测、可回滚、成本可控。企业里真正跑在生产上的，绝大多数是这一类而不是自主 agent。4. 开源框架（自己搭）LangGraph（状态机式，可控性最好）、AutoGen（多 agent 对话）、CrewAI（角色扮演式，上手快）、LlamaIndex（偏 RAG）。本地部署栈常见 vLLM/Ollama + OpenWebUI + Qdrant/Milvus。自己搭的代价是要处理工具调用容错、上下文压缩、并发与限流，工程量不小。怎么选（按场景）· 写代码 → IDE 内 agent，收益/成本比最高；· 固定业务流程（客服、报告生成、数据清洗）→ 工作流编排，别上自主 agent；· 探索性任务、一次性脚本 → 通用 agent 或直接让编码 agent 写脚本；· 有数据合规要求 → 开源框架 + 私有化模型，别无选择。一个务实建议：先别纠结框架，把「工具层」做扎实——把你系统里的能力（查询、写库、发消息）封装成清晰的、有 schema 的函数，任何 agent 框架接进来都能跑。工具层设计得好，换框架成本几乎为零；工具层一塌糊涂，换什么框架都难用。

选型最容易犯的错是「先挑配置再想业务」，正确顺序是先定位瓶颈资源，再按瓶颈选族，最后用计费方式省钱。一、先判断你的负载类型· CPU 密集（编译、转码、加解密、计算）：看主频与 vCPU，选计算型；· 内存密集（Redis、ES、JVM 大堆、数据库）：内存/vCPU 比要 4:1 甚至 8:1，选内存型；· IO 密集（数据库、日志、消息队列）：瓶颈在磁盘 IOPS 与吞吐，云盘规格比 CPU 更关键；· 网络密集（网关、代理、CDN 回源）：看内网带宽与 PPS，选网络增强型；· 潮汐型/低负载（个人站、测试环境）：突发性能型，靠 CPU 积分跑突发。二、几个容易被忽略的性能陷阱1. 突发性能型的积分耗尽：基线通常只有 20%~30%，积分用完就降频到基线，表现为「跑一会儿突然变卡」。生产环境别用它扛持续负载。2. 云盘的 IOPS 才是数据库的命门：ESSD 分 PL0/PL1/PL2/PL3，IOPS 与容量挂钩（容量越小 IOPS 上限越低）。MySQL 建议 PL1 起步，且容量别小于 100G，否则 IOPS 撑不住写入。3. 带宽计费方式：固定带宽（按 Mbit 包月）适合流量平稳；按流量计费适合波峰明显但总量小的场景。注意内网流量免费，同区域多台机器通信走内网能省一大笔，别让服务绕公网。4. vCPU 是超线程：1 vCPU 通常是 1 个超线程，物理核性能约为其 1.5~2 倍。单线程敏感的业务（如某些 Java 服务）要按物理核折算。三、省钱手段（按收益排序）① 包年包月 vs 按需：长期稳定负载包年包月通常比按需便宜 50% 以上；短期/不确定用按需，用完即释放。② 弹性伸缩：无状态服务配 ASG，低谷缩到 1 台，比固定 4 台省得多。③ ARM 架构：鲲鹏实例同规格价格更低，前提是镜像和依赖有 aarch64 版本（Docker 多架构镜像基本没问题）。④ 轻量应用服务器：个人站、小流量 API 用它比 ECS 便宜很多，缺点是规格固定、扩展性差。⑤ 闲置资源清理：挂载未使用的 EIP、快照、按需实例最容易漏钱，开个账单告警。四、别靠猜，压测一遍CPU：sysbench cpu --threads=N run；内存：sysbench memory run；磁盘：fio --rw=randwrite --bs=4k --iodepth=32 --numjobs=4；网络：iperf3 -c 对端。先小规格压出单机 QPS，再按目标流量线性外推并留 30% 余量。经验值：Web 应用单核 200~800 QPS（看框架），据此反推核数是比「凭感觉选 4C8G」靠谱得多的做法。

CSRF 的本质是浏览器会自动携带目标站 cookie，而服务端无法区分「用户本人发起的请求」和「第三方页面伪造的请求」。防御的核心就一句话：让伪造请求无法同时满足「有凭证」和「有服务端预期的东西」。一、攻击面长什么样三种典型载体：① 自动提交表单+ JS 自动 submit；② 打 GET 写操作；③ JSON 接口用 enctype=text/plain 或表单字段名拼成 JSON 绕过 content-type 校验。还有登录 CSRF（把受害者登进攻击者的账号，进而诱导其输入敏感信息）。二、防御，按性价比排序1. SameSite Cookie（成本最低、覆盖最广）会话 cookie 设 SameSite=Lax（或 Strict）+ Secure + HttpOnly。Lax 会拦掉绝大部分跨站 POST 和 img GET 的 cookie 携带，现代浏览器默认已是 Lax，但显式声明才能覆盖老客户端。注意：如果你的站点需要跨站单点登录回跳，Strict 会导致回跳后没有会话，通常用 Lax。2. CSRF Token（标准解）服务端下发随机 token（绑定 session 或 HMAC 签名），前端放在 header 或表单隐藏域，服务端校验。要点：token 必须不可预测、与用户会话绑定、校验失败直接拒绝而不是降级。同步器模式（session 内存 token）和双提交 cookie（cookie + header 各放一份，服务端比对）都可，前者更安全、后者对无状态服务更友好。3. Origin / Referer 校验对状态变更请求校验 Origin（优先）或 Referer 是否在白名单内。Origin 在现代浏览器上对 POST 一定带，比 Referer 更可靠（Referer 会被隐私策略裁掉）。这是很好的第二道防线。4. 自定义 header 强制预检要求请求带 X-Requested-With 或自定义 token header。跨站表单无法设置自定义 header，会触发 CORS 预检，而预检不通过请求就到不了业务逻辑。纯前后端分离项目很实用。5. 语义层面的约束· 写操作一律 POST/PUT/DELETE，GET 幂等；· 敏感操作二次验证（密码/短信/图形验证码）；· 关键接口校验 Content-Type: application/json 并拒绝 text/plain；· CORS 不要图省事写 Access-Control-Allow-Origin: * 配 Allow-Credentials: true（浏览器本身也会拒绝这种组合，但配置混乱常导致误判）。三、常见误区① 以为用了 JWT 放 header 就安全——如果 token 存 localStorage 由 JS 读取确实天然免疫 CSRF，但同时打开了 XSS 的口子，且跨标签页共享会带来新问题；② 只在登录接口做防护，业务接口裸奔；③ token 放在 URL 里（会被 Referer 泄漏到第三方）；④ 校验失败时「容错放行」。落地建议：框架自带的 CSRF 中间件（Spring Security / Django / Laravel）默认就够用，别自己造轮子；上线前用 OWASP ZAP 的 CSRF 扫描过一遍，重点验证「去掉 token 的请求是否被拒」。

「跑一段时间就断」几乎都是资源泄漏或被系统杀掉，而不是代码逻辑错。按下面顺序查，基本一轮就能定位：1. 先确认它是怎么死的（最关键）看退出码：137 = 被 SIGKILL（大概率 OOM killer 或容器内存超限）、143 = SIGTERM（被调度器/超时踢掉）、1 = 自己抛异常退出。dmesg -T | grep -i "killed process" 能直接看到是不是 OOM；在容器里看 docker inspect 的 OOMKilled 字段。2. 内存泄漏（最常见）用 ps -o rss= -p PID 每 10 秒采一次，画曲线：单调上升不回落就是泄漏。典型来源：· requests 的 Session 用完没 close()，连接池对象累积；· 全量 response.text 存进 list 当缓存，页面越爬越大；· 解析库（lxml/BeautifulSoup）持有 DOM 引用，循环里没释放；· asyncio 里 create_task 不 await，任务对象堆积；· 全局字典做去重（seen set）无限增长。处理：去重集合落盘（SQLite/Redis）或加 LRU 上限；响应体用 stream=True 边下边处理；定期 gc.collect() 并排查循环引用。3. 文件句柄耗尽lsof -p PID | wc -l 接近 ulimit -n（默认 1024）就会 Too many open files。多见于日志文件不轮转、临时文件不删、socket 未关闭。处理：ulimit -n 65535，日志用 logging.handlers.RotatingFileHandler 或交给 logrotate。4. 连接与端口ss -s 看 TIME_WAIT 数量；短连接高频请求会打满本地端口（约 2.8 万个）。处理：复用 Session + HTTPAdapter(pool_maxsize=...)，或改用长连接。5. 被目标站封禁表现是突然全部 403/429/超时。加请求间隔、UA 池、指数退避重试；不要用无限重试，重试要有上限并把失败项落队列。工程上的根治办法：把爬虫做成可恢复的——① 用 systemd 或 supervisor 托管，挂了自动拉起；② 待爬队列与已爬状态持久化（SQLite 一张表即可），重启后从断点继续；③ 每个 URL 处理独立事务，失败记次数，超过阈值进死信队列；④ 关键指标（成功率、平均耗时、内存、队列长度）打日志，出问题能回溯。做到这四点，「断」就只是个小插曲而不是事故。