解读

在国内 PHP 面试中，面试官问“Cache 与 Artifacts 区别”并不是考英语翻译，而是想确认候选人是否真正理解“运行时加速”和“构建时产出”这两个完全不同的工程概念。很多候选人把 Redis、OPcache 叫“缓存”，把编译后的 .phar、vendor、前端 dist 目录也叫“缓存”，结果一追问就露馅。回答时必须结合 PHP 实际工作流：Composer 安装后生成的 vendor 是 Artifact，OPcache 或 Redis 里的数据才是 Cache；CI/CD 里打包的镜像、tar 包也是 Artifact，而流水线里为了提速而暂存的 vendor 缓存属于 Cache。区分不清会导致线上误删、回滚失败、扩容脚本写错，这是国内中小公司到一线大厂都会踩的坑。

知识点

1. 生命周期：Cache 可失效、可重建，生命周期短；Artifacts 一旦生成即被视为“版本冻结”的交付物，生命周期与版本绑定。
2. 生成时机：Cache 由运行阶段根据热点数据动态生成；Artifacts 在构建或打包阶段一次性生成。
3. 可抛弃性：Cache 随时可清空，不影响功能；Artifacts 被删除则部署中断，必须重新构建或从制品库拉取。
4. 存储位置：Cache 通常放 Redis、Memcached、本地内存、OPcache shared memory；Artifacts 放对象存储（阿里云 OSS、腾讯云 COS）、私有 Nexus、Harbor、GitHub Packages。
5. 内容形态：Cache 是 KV、序列化对象、查询结果、HTML 片段；Artifacts 是完整可执行实体，如 .phar、Docker 镜像、vendor 目录、前端 dist、移动端 apk。
6. 一致性要求：Cache 允许短暂不一致，最终一致即可；Artifacts 要求强一致，md5/sha256 校验失败即拒绝发布。
7. 国内合规：等保 2.0 要求缓存数据加密传输；Artifacts 必须存储在境内节点，涉及开源许可证审计（GPL 传染风险）。

答案

Cache 是运行时为了提速而临时存储的热点数据，可丢失、可重建，典型如 Redis 缓存、OPcache 字节码、CDN 边缘缓存；Artifacts 是构建阶段产出的不可变交付物，一旦生成即对应唯一版本，如 vendor 目录、.phar 包、Docker 镜像、前端 dist，必须入库管理，丢失后无法运行。核心区别：生命周期、可抛弃性、生成时机、存储目的。落地到 PHP 项目，Composer install 生成的 vendor 是 Artifact，而线上 Redis 里缓存的用户会话是 Cache；CI 里为提高构建速度把 vendor 目录缓存到 /tmp/cache，这个缓存本质还是 Cache，不是 Artifact。

拓展思考

1. 灰度场景：国内大厂常把 Artifact 做成“双版本”并存（蓝绿），Cache 则按百分比灰度清理，如何防止新 Artifact 上线后旧 Cache 造成脏读？可在 Cache Key 中加入 Artifact 版本号或 git commit 前 7 位，实现“缓存与版本绑定”。
2. 成本优化：OSS 存储 Artifact 要付钱，阿里云低频访问型 IA 存储比标准型便宜 40%，但取回需要分钟级延迟；对回滚频率低的历史版本可定时沉降，脚本用阿里云 OSS Lifecycle 规则即可。
3. 安全合规：Artifacts 里若包含公司私有包，需在内网 Nexus 配置“匿名禁止拉取”，同时给 Cache 开启 TLS 1.3 并关闭 TLS 1.0/1.1，满足金融客户渗透测试要求。
4. 微服务：PHP 业务容器化后，Artifacts 是镜像层，Cache 是 Sidecar Redis；当 Pod 弹性伸缩，Kubernetes 的 descheduler 会驱逐 Pod，若把 Session 落到文件 Cache 将丢失，需改用中央 Redis 并开启 AOF 持久化。