NextJS中router.pathname与router.route的区别及使用注意事项

Hey JayCodist! Great question—let’s clear up the confusion between pathname and route in Next.js’s useRouter hook, plus cover the key pitfalls to watch out for when fetching page URLs.

Key Differences Between pathname and route #

In the Pages Router (which uses useRouter from next/router), these two properties are closely related but have subtle (and sometimes context-dependent) differences:

• pathname: This directly maps to the file path of your page component in the pages directory. For example, if you have a dynamic route at pages/post/[id].js, pathname will always be /post/[id]—even when a user visits /post/123 or /post/456. It’s a static reference to your page’s physical location in the codebase, not the actual URL the user sees.
• route: In most standard use cases, this will match pathname exactly. It represents the internal route pattern that Next.js uses to match incoming requests to your page component. The only time you might see a difference is if you’re using advanced routing features like rewrites in next.config.js—in some edge cases, route could reflect the original requested path before rewrites are applied, while pathname stays tied to the actual page file. That said, for most everyday development, you can treat them as interchangeable.

Pitfalls to Avoid When Fetching the Page URL #

If your goal is to get the actual full URL that’s displayed in the user’s browser, pathname and route are not the right tools—here’s why and what to use instead:

• They don’t include dynamic parameter values: As mentioned, both pathname and route use the placeholder syntax ([id]) instead of the actual values from the URL. To get the visible path (like /post/123), use router.asPath instead.
• They don’t include the origin/domain: Neither property includes the base URL (like https://yourdomain.com). To build the full URL, combine window.location.origin with router.asPath:

  const router = useRouter();
  const fullUrl = `${window.location.origin}${router.asPath}`;
  

• Server-side limitations: useRouter is a client-side hook—you can’t use it directly in server-side rendering (SSR) or static site generation (SSG) functions like getServerSideProps or getStaticProps. In those cases, use the context object passed to these functions to access route info:

  export async function getServerSideProps(context) {
    // Build full URL using request headers and url
    const fullUrl = `https://${context.req.headers.host}${context.req.url}`;
    // Access dynamic parameters via context.params
    const postId = context.params.id;
    return { props: { fullUrl, postId } };
  }
  

• App Router differences: If you’re migrating to Next.js 13+’s App Router, note that useRouter from next/navigation replaces the old hook. In App Router, pathname now represents the actual URL path (with dynamic values filled in), and the route pattern (like /post/[id]) is accessed via useMatches() instead—so be mindful of version-specific behavior.

内容的提问来源于stack exchange，提问作者JayCodist