标签：#querystring

The symptom is simple: you open /dashboard?search=invoice&page=2 , copy an old snippet, and get undefined , stale values, or the wrong API entirely. The root cause is that Next.js now has two routing models, and the correct query-string API depends on where you read the params: App Router Server Component page: use the searchParams prop App Router Client Component: use useSearchParams() Shared client component across both routers: useSearchParams() still works Here is the exact fix for each case. The App Router server-side fix If you are inside app/.../page.tsx , use the page prop. In the current Next.js docs, searchParams is a promise in modern App Router pages. // app/dashboard/page.tsx export default async function Page ({ searchParams , }: { searchParams : Promise < { [ key : string ]: string | string [] | undefined } > }) { const { search = '' , page = ' 1 ' } = await searchParams return ( < main > < h1 > Dashboard </ h1 > < p > Search: { search } </ p > < p > Page: { page } </ p > </ main > ) } Use this when the query string affects data fetching, pagination, filtering, or metadata for the page itself. The App Router client-side fix If the component is interactive and already marked 'use client' , use useSearchParams() from next/navigation . ' use client ' import { useSearchParams } from ' next/navigation ' export default function SearchSummary () { const searchParams = useSearchParams () const search = searchParams . get ( ' search ' ) ?? '' const page = searchParams . get ( ' page ' ) ?? ' 1 ' return ( < p > Searching for < strong > { search || ' everything ' } </ strong > on page { page } </ p > ) } Two details matter: useSearchParams() is read-only. In the App Router docs, Next.js explicitly recommends the page searchParams prop if you are already in a Server Component page. The shared-component pattern that survives both routers This is the cleanest answer if you are migrating gradually or sharing a search bar between pages/ and app/ . ' use client ' impo