菜单
Use when the user adds a cache layer, memoizes a fetch, sets a Redis/KV key, configures Next.js fetch caching, or sees stale-data complaints. Covers cache keys, TTL choice, stampede prevention, invalidation strategies, and the per-user vs global trap.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when the user creates a route handler, Server Action, RPC endpoint, or any HTTP endpoint that mutates state or accepts user input. Covers rate limiting, body-size caps, request timeouts, idempotency keys, error response contracts, and method/CORS hygiene.
Use when the user is wiring login, signup, logout, OAuth, JWTs, session cookies, "remember me", password reset, magic links, or token storage. Covers httpOnly cookies vs localStorage, CSRF, session rotation, password hashing, logout-everywhere.
Use when the user writes any endpoint, server action, route handler, or query that reads or mutates user-owned data — anything taking a resource ID from the request. Catches IDOR, missing row-level checks, "logged in" mistaken for "allowed to," and role/permission gaps.
Use when the user stores user data, PII, payment info, health/biometric data, builds export/delete features, signs up for data processors, configures backups, or designs cross-border data flows. Covers encryption at rest/transit, deletion paths, audit logs, what to never log, and minimum-data principles.
Use when the user writes raw SQL, Drizzle/Prisma/Kysely queries, ORM `findMany` / `findUnique` calls with user input, or anything constructing a query from request data. Covers parameterization, N+1 detection, missing indexes, SELECT *, query plans, and unbounded result sets.
Use when the user writes try/catch, throws errors, builds error boundaries, returns errors from an API, sets up global error handling, or designs how failures surface to users. Catches swallowed errors, leaked internals in error responses, missing graceful degradation, and "the spinner spins forever" UX.
| name | caching-and-invalidation |
| description | Use when the user adds a cache layer, memoizes a fetch, sets a Redis/KV key, configures Next.js fetch caching, or sees stale-data complaints. Covers cache keys, TTL choice, stampede prevention, invalidation strategies, and the per-user vs global trap. |
"There are only two hard things in computer science: cache invalidation and naming things." — Phil Karlton. The corollary: don't add a cache until you've measured a problem the cache solves.
cache(), unstable_cache, 'use cache', revalidatePath, revalidateTag// BAD — same key for every user. First user's data leaks to every user.
const cache = new Map<string, User>()
async function getUser() {
if (cache.has('user')) return cache.get('user')
const u = await fetchCurrentUser()
cache.set('user', u)
return u
}
// GOOD — keyed by what varies
async function getUser(userId: string) {
const k = `user:${userId}`
const hit = await redis.get<User>(k)
if (hit) return hit
const u = await db.user.findUnique({ where: { id: userId } })
await redis.set(k, u, { ex: 60 })
return u
}
If the result depends on userId, tenantId, locale, A/B variant — every one of those goes in the key.
This is the same bug, two directions. A cache keyed without the user leaks one user's data to all. A cache keyed by user when the data is global wastes memory at near-100% miss rate.
In Next.js: cache() and 'use cache' are request-scoped or content-keyed. If you cache a function whose result depends on cookies()/headers(), include those in the key explicitly or you'll cross-contaminate users.
| Data | TTL | Why |
|---|---|---|
| User profile | 30s–5min | rare changes, OK to be slightly stale |
| Marketing page | hours | content rarely changes; revalidate on publish |
| Pricing page | minutes + tag-based revalidation | needs invalidation on price change |
| Auth permissions | seconds, or don't cache | wrong = security incident |
| Account balance | don't cache | wrong = correctness incident |
"Forever" is a TTL only if you have invalidation. Always pair long TTLs with a deliberate invalidation plan.
Next.js 15+:
// Read
const data = await fetch(url, { next: { tags: ['post:42'] } })
// Or with use cache (Next 15+)
async function getPost(id: string) {
'use cache'
cacheTag(`post:${id}`)
cacheLife({ revalidate: 3600, expire: 86400 })
return db.post.findUnique({ where: { id } })
}
// Invalidate when the post changes
await revalidateTag(`post:${id}`)
Tags let you invalidate a single logical entity across every cache that touched it. Path revalidation is a blunt instrument; time-based is a fallback for "we forgot to invalidate."
When a hot key expires, every concurrent request misses → all hammer the origin → the origin falls over.
Options:
revalidate.)SETNX lock; concurrent misses wait or return stale.// BAD — every "not found" hits the DB. A scraper looking for valid IDs DDoSes you.
const post = await db.post.findUnique({ where: { id } })
if (!post) return notFound()
// GOOD — short-TTL "not found"
const cached = await redis.get(`post:${id}`)
if (cached === '__null__') return notFound()
const post = await db.post.findUnique({ where: { id } })
if (!post) {
await redis.set(`post:${id}`, '__null__', { ex: 30 })
return notFound()
}
GET is cacheable; POST/PUT/PATCH/DELETE are not. If something feels cacheable but mutates, it's modeled wrong.
Shipped a code change that changes the shape of cached data? Old cached entries are now poisoned. Two safe patterns:
v2:user:42 — old v1: keys age out, new ones populate.Never deploy a "I'll just keep using the same key with the new shape" change. Old data + new code = type error in production.
A cache keyed by ?search=<random> lets attackers fill it with garbage that no one will hit again. Defenses:
Without metrics you don't know the cache works. Track:
name, region)If hit rate is < ~70% on a hot path, the cache is probably a net loss after key/TTL/serialization overhead. Re-evaluate.
'use cache' + cacheTag + cacheLife is the modern primitive. Prefer it over unstable_cache.fetch(url, { next: { revalidate, tags } }) for data-fetching caches.revalidateTag in a Server Action after a mutation is the canonical "data changed, invalidate."See next-cache-components for deeper Next.js 15+ details.
A "trending posts" page used unstable_cache keyed by route path. It rendered a personalized "for you" panel. After the cache populated for the first user, every subsequent visitor saw that user's recommendations — including their private "saved drafts" preview. Discovered when one user reported seeing another user's name. Fix: include userId in the cache key, plus a 'use server' audit pass for any cache that touched session state.