Dai Wei

围绕“Docker 核心概念总结”，本文不按原目录复述，而是把内容整理为问题、机制、实践和取舍四层。阅读时可从“容器介绍、什么是容器、图解物理机、虚拟机与容器、容器 VS 虚拟机”几个切面建立自己的判断框架。 核心认识开发工具的价值是让构建、运行和协作可重复。理解状态、依赖、版本与执行阶段，比记忆命令更重要；工具异常通常也应沿这些边界排查。 镜像是分层只读模板，容器是带可写层的运行实例，关键数据应放入外部卷。生产镜像宜多阶段构建、固定基础版本、非 root 运行并配置资源和健康检查。 学习这类主题时，应先写清对象、边界和衡量指标，再讨论具体组件或技巧。同一方案放在不同流量、数据规模与团队能力下，结论可能相反；设计说明必须保留前提。 工程实践团队应固定工具入口与关键版本，让本地和 CI 执行同一流程。配置变更要能通过日志、依赖图或产物校验验证，并保留安全的回退方式。 实施建议采用小步验证：记录变更前基线，一次只调整少量关键变量，通过日志、指标和测试判断收益。上线后继续观察长尾与异常路径，并把操作步骤沉淀成可执行预案。 权衡与边界自动化提高效率，也可能隐藏隐式行为和供应链风险。配...

场景“忘记密码”如果能返回原密码，说明服务端保存了可逆明文或可解密副本；一旦数据库或密钥泄露，所有用户凭证会立即暴露。 原理安全系统保存的是口令经盐和慢哈希函数计算后的验证值。登录时对输入使用相同参数计算并比较，服务端没有原文可读。独立随机盐阻止彩虹表复用，较高计算成本提高离线破解代价。 设计步骤注册时使用 Argon2id、bcrypt 等成熟实现并保存算法版本、盐与成本参数；登录采用常量时间比较；忘记密码签发一次性、短时、绑定用户的重置令牌；重置成功后撤销旧会话并发送安全通知。 权衡更高哈希成本提升抗破解能力，也增加登录 CPU 和拒绝服务风险，需要压测。通过邮件或短信重置方便，但安全性取决于外部账户；客服人工找回灵活，却容易遭遇社工攻击。 实践建议全程使用 HTTPS，但不要把前端哈希当作服务端口令哈希替代。重置接口不泄露账号是否存在，令牌只保存哈希并限制尝试次数。定期评估成本参数，用户成功登录时渐进升级旧哈希；禁止在日志、埋点和异常中记录密码。 落地检查上线前还应做一次桌面演练：准备正常、边界、超时、重复与恶意输入，确认系统的返回、日志和指标彼此对应；在预发布环境模拟...

场景评论系统词库从几百增长到几十万后，逐词扫描会拖慢请求；用户插入空格、符号或同音变体又能绕过简单匹配。 原理暴力匹配对每个词重复扫描文本，Trie 利用公共前缀减少比较，AC 自动机通过失败指针在一次扫描中匹配多模式。双数组 Trie 改善内存布局。工程上还要在匹配前做规范化，并处理最长匹配和重叠结果。 设计步骤先定义拦截、替换、标记等业务策略；对文本统一大小写、全半角和可接受的符号；按词库规模选择 Trie 或 AC 自动机；构建不可变词典并原子热切换；记录命中规则版本，离线评估误杀与漏检。 权衡规范化越激进越能对抗变体，也越可能误伤正常表达。同步过滤结果及时但占用请求延迟；异步审核吞吐高，却允许内容短暂可见。布隆过滤器只能快速判断“可能存在”，不能替代精确匹配。 实践建议词库按业务、语言和风险分级，变更经过审核与回滚。超长文本限制长度或分段时保留模式边界。监控耗时分位、命中率、词库大小和更新失败。敏感词系统只是内容治理的一层，复杂语义仍需模型和人工复核。 落地检查上线前还应做一次桌面演练：准备正常、边界、超时、重复与恶意输入，确认系统的返回、日志和指标彼此对应；在预发布...

场景“把数据加密”并不是一个完整需求：密码登录、接口传输、文件保密和数字签名需要的安全目标完全不同，选错算法可能看似安全却无法抵御攻击。 原理哈希是单向摘要，适合完整性校验；口令应使用带盐且计算昂贵的 bcrypt、scrypt 或 Argon2。AES 等对称加密速度快，适合大数据；RSA、椭圆曲线等非对称算法便于密钥交换与签名，通常与对称算法组合使用。 设计步骤先明确机密性、完整性、身份认证或不可否认性；采用成熟协议和库；数据使用随机内容密钥加密，再用密钥管理系统保护内容密钥；为密文保存算法和版本；设计轮换、吊销、备份与审计。 权衡更高计算成本可抵抗口令暴力破解，也消耗服务器资源；非对称加密便于分发但速度慢且载荷受限。可搜索或可比较的数据往往泄露模式，应在功能便利与隐私之间明确取舍。 实践建议禁用 MD5、SHA-1 作为密码存储，禁用 ECB 和自制协议。使用带认证的加密模式如 AES-GCM，并保证 nonce 不重复。密钥不进仓库、不写日志，权限按用途隔离。算法升级采用版本化密文和读取时迁移，不要求一次性停机重加密。 落地检查上线前还应做一次桌面演练：准备正常、边界...

场景企业后台拥有系统、菜单、接口和数据多种权限，只给用户挂角色很快会遇到临时授权、跨部门数据范围和审批追踪问题。 原理RBAC 通过用户、角色、权限降低管理规模，ABAC 再根据主体、资源与环境属性做动态决策。权限系统应把权限定义、分配关系、策略计算和审计分开，业务系统负责提供资源上下文并执行决定。 设计步骤先枚举资源与动作并使用稳定权限码；设计用户—角色—权限关系和数据范围；区分默认角色与自定义角色；增加申请、审批、生效、到期、回收流程；决策接口默认拒绝，变更写审计日志并支持影响分析。 权衡权限粒度粗易维护但容易过度授权，粒度细更安全却产生角色爆炸。集中决策一致性高，但增加网络依赖；本地缓存性能好，却存在策略更新延迟。ABAC 灵活，却比 RBAC 更难解释和排查。 实践建议权限码不要绑定菜单名称，前端隐藏按钮也不能代替后端检查。高风险权限设置期限和复核；缓存携带策略版本并支持主动失效；管理员同样受权限治理。上线前用权限矩阵验证正向与反向场景，并定期清理孤儿角色。 落地检查上线前还应做一次桌面演练：准备正常、边界、超时、重复与恶意输入，确认系统的返回、日志和指标彼此对应；在...

场景注册表单在浏览器提示格式正确，并不能阻止攻击者直接调用 API；服务端只做格式校验，也无法给普通用户及时友好的反馈。 原理前端校验关注交互体验，服务端校验承担安全与数据完整性。字段约束检查长度、格式和范围，业务约束检查唯一性、状态和关联关系，权限校验确认当前主体能否操作目标资源。三者失败语义不同。 设计步骤为 DTO 声明基础约束并在入口触发；跨字段规则使用对象级校验；涉及数据库状态的规则在事务内再次判断；权限检查基于服务端查出的资源而非客户端传入归属；错误响应返回稳定代码和字段路径。 权衡重复校验增加维护成本，却是跨信任边界必要冗余。注解适合静态规则，复杂业务若塞进自定义校验器会隐藏数据库访问和事务。过严过滤可能拒绝合法输入，过松则把风险推给后续层。 实践建议采用白名单和长度上限，规范化后再验证，防止 Unicode 或编码绕过。校验失败不回显敏感内部信息。唯一性仍需数据库约束兜底，不能只靠“先查询”。把恶意输入、并发提交和对象越权加入自动化测试。 落地检查上线前还应做一次桌面演练：准备正常、边界、超时、重复与恶意输入，确认系统的返回、日志和指标彼此对应；在预发布环境模...

场景一个用户成功登录，并不代表他可以读取任意订单。把认证与授权混在控制器里，会导致重复代码和越权漏洞。 原理认证验证主体身份，授权依据主体、动作、资源和环境做决策。Cookie 是浏览器保存并自动发送的数据，Session 是服务端会话状态；JWT 是可签名的声明载体。OAuth 2.0 处理委托授权，SSO 则让多个应用复用统一登录状态。 设计步骤先定义身份源和登录强度；再选择 Session 或令牌并设计过期、续期、注销；将授权放在资源访问前且服务端执行；集群 Session 使用共享存储或一致路由；跨站请求配置 CSRF、防重放和 Cookie 安全属性。 权衡Session 易撤销且载荷小，但水平扩展需要共享状态；JWT 验证本地化，却有撤销与体积成本。RBAC 管理直观，面对资源属性和上下文时可能需要 ABAC。SSO 改善体验，也扩大身份中心故障影响。 实践建议401 表示尚未有效认证，403 表示身份明确但无权限。认证结果只提供主体，不替代对象级授权。会话 ID 必须随机并在登录后轮换；敏感操作重新认证。审计记录谁在何时对何资源执行何动作，同时避免写入凭证本身。...

场景多服务和移动端需要携带身份时，JWT 可以减少中心会话查询；但用户登出、权限收回后令牌仍有效，常让团队措手不及。 原理JWT 由头、载荷和签名组成，签名保证内容未被篡改，并不负责加密。服务只凭密钥即可验证，形成无状态扩展能力；与此同时，签发后的令牌在过期前天然独立，撤销和续签需要额外状态。 设计步骤访问令牌设置短有效期，只放最小声明；刷新令牌单独保存并支持轮换；服务验证签名算法、发行者、受众与时间；注销或高风险变更写入撤销记录；网关统一解析，但下游仍做资源授权。 权衡短令牌窗口更安全，却增加刷新请求；黑名单恢复即时撤销，却重新引入存储与查询。把 JWT 放 Authorization 头可降低传统 Cookie 自动携带导致的 CSRF 风险，但仍要防 XSS 窃取。 实践建议固定允许算法，绝不信任令牌自行声明的任意算法；不要存密码、隐私或频繁变化权限。密钥按 kid 轮换，时钟允许小范围偏差。浏览器存储方案需结合威胁模型选择；若业务强依赖即时会话控制，服务端 Session 往往更直接。 落地检查上线前还应做一次桌面演练：准备正常、边界、超时、重复与恶意输入，确认系统的...

场景登录、权限、加密、脱敏和校验若由各业务自行实现，规则会不一致，也容易出现前端校验被绕过或敏感数据进入日志。 原理认证回答“你是谁”，授权回答“你能做什么”；Session、JWT 与 SSO 解决身份状态传播；RBAC、ABAC 决定资源访问；加密保护机密性，哈希用于完整性或口令验证，脱敏减少展示暴露，校验守住输入边界。 设计步骤先盘点主体、资源和敏感数据；划分浏览器、网关、服务与数据库的信任边界；选择身份载体并定义撤销机制；建立最小权限模型；对传输、存储、日志分别制定保护措施；最后做威胁建模和审计演练。 权衡集中安全能力统一治理，却可能成为瓶颈和单点；JWT 易扩展但撤销复杂，Session 易控制但需要共享状态。权限粒度越细管理成本越高，脱敏越强则排障和运营可用性越低。 实践建议默认拒绝并显式授权，服务端永远重新校验。密钥与代码分离并定期轮换；日志不记录令牌、密码和完整个人信息；高风险操作二次认证。把失败登录、越权拒绝、密钥异常和脱敏命中纳入监控，安全才是可运行系统而非文档。 落地检查上线前还应做一次桌面演练：准备正常、边界、超时、重复与恶意输入，确认系统的返回、日志...

场景网关能 Base64 解出 JWT 载荷，不代表令牌可信。若只读取用户 ID 而不验证签名、发行者和受众，攻击者可以自行构造身份。 原理JWT 紧凑表示由 Header、Payload、Signature 三段组成。前两段是 Base64URL 编码而非加密；签名覆盖头与载荷。解析只是读取内容，验证还必须校验密码学签名和 exp、nbf、iss、aud 等声明。 设计步骤服务端固定允许算法并按 kid 获取可信密钥；先验证签名，再检查发行者、受众和时间；从 sub 建立主体上下文；授权层结合当前资源重新判断权限；失败统一返回认证错误并记录不含令牌的追踪信息。 权衡对称签名部署简单，但每个验证方都拥有签发能力；非对称签名可分离私钥签发和公钥验证，密钥管理更复杂。载荷越丰富可少查数据，却增加泄露、体积和信息过期风险。 实践建议令牌通过 HTTPS 传输，生命周期尽量短，不放敏感数据。拒绝 none 与算法混淆，缓存公钥时保留轮换窗口。对时钟偏差设置有限容忍。JWT 只证明签发时的声明可信，业务仍需处理账户禁用、权限变化和重放风险。 落地检查上线前还应做一次桌面演练：准备正常、...