· 全部指南
MIME 类型基础与自动识别
MIME 类型由类型/子类型组成（如 image/png），浏览器通过文件签名（Magic Number）而非扩展名识别真实类型。使用 Towalles 的 mime-types 工具上传文件可立即验证实际类型，避免恶意文件伪装（如 .exe 改名为 .jpg）。本地处理确保敏感文件不上传服务器，符合隐私优先原则。
常见陷阱包括将 CSS 文件误设为 text/plain 导致浏览器不解析，或 JSON 接口未指定 application/json 引发安全警告。开发时应优先使用标准类型而非自定义 x- 前缀类型，除非有特殊兼容需求。
Content-Type 头设置规范
HTTP 响应必须包含正确的 Content-Type 且附带 charset（如 text/html; charset=utf-8），否则可能导致乱码或 XSS 漏洞。API 开发中忘记设置 Accept 和 Content-Type 头是跨域问题的常见诱因，特别是对非简单请求（如 application/json）。
文件下载需指定 Content-Disposition: attachment，而内联展示则用 inline。动态生成文件时（如导出 CSV），应同时设置 Content-Type 和 Content-Disposition 以确保浏览器正确处理。
文件上传与 multipart/form-data
表单文件上传必须设置 enctype="multipart/form-data"，每个文件部分会自动包含 Content-Type。后端若仅依赖扩展名验证类型，攻击者可伪造图片上传恶意脚本，应结合文件签名验证（如 PNG 头总是以‰PNG 开头）。
大文件上传时需注意：浏览器对 multipart 请求有默认大小限制，Nginx 等代理可能需要调整 client_max_body_size。分片上传可考虑流式处理而非内存缓冲，避免服务器过载。
Base64 数据 URI 的典型错误
数据 URI（data:image/png;base64,...）需完整包含 MIME 类型声明，否则浏览器可能按 text/plain 处理。通过 Towalles 的 base64-file-converter 工具可安全地在本地测试转换效果，无需上传真实文件。
性能注意：Base64 编码会使文件体积增长约 33%，不适合大文件内联。CSS 中少量使用 SVG 图标是理想场景，而超过 10KB 的图片应优先考虑外部资源引用。
Content-Type 是契约
浏览器与 API 更相信 Content-Type，而不是扩展名。把 JavaScript 当成 text/plain、把 JSON 当成 text/html 会导致隐蔽的 XSS 与解析问题。文本类型应显式声明 charset。
上传
服务端同时校验声明的 MIME 与嗅探内容。客户端提供的类型只是提示，不是证明。用户上传白名单保持精短。
排障
下载「打开是乱码」时先看响应头。确认载荷编码后，再用本地格式化工具。
安全附注
攻击者可控上传若返回 Content-Type: text/html 极易 XSS。可能时把用户内容放到独立域，并配合收紧的 CSP。
HTTP Content-Type 纪律
动生产前先写操作程序：输入、期望输出、负责人与回滚。Towalles 上的工具便于本地检查样例，不能替代变更控制。
前置条件
- 有代表失败案例的脱敏 fixture。
- 清楚谁是真相来源（应用、网关、CMS 或网络设备）。
- 能在非生产环境或用合成数据复现问题。
步骤
- 用 fixture 复现，记录精确命令或 UI 路径。
- 按需用格式化、哈希或解析工具与已知正确样例对照。
- 做最小修复；同一变更里避免顺手重构。
- 补充回归测试或清单项，避免下一任 on-call 重复踩坑。
- 更新 runbook：症状 → 检查 → 修复。
善后
观察 24–72 小时错误率与支持工单。若做过一次性数据修复，安排后续防止复发。工单里保留截图与哈希，不要留真实密钥。
反模式
- 把生产密钥贴到公开页面「只是看一下」。
- 上线却不写回滚说明。
- 把本地绿色演示当成多区域生产的证明。