最も関連性があり注目すべき問題は＃1189と＃3876です

これが最終的に解決されるのを楽しみにしています！ @timneutkens Next 7の末尾のスラッシュの問題のステータスはどうなっていますか？

@NathanielHill next @ 7で再現できます

私はnextjs7を使用しており、末尾のスラッシュはdevとprodの両方で404を生成しています。

• 最初のページの読み込み時
• ページの更新

そして影響：

• 外部リンク
• 内部リンク
• ブラウザに貼り付けられたURL

末尾のスラッシュを削除するだけで問題が解決します。

末尾のスラッシュは、リンクが貼り付けられる可能性のあるブラウザ、サーバー、その他のサービスによって追加されることが多いため、内部リンクを制御することはできますが、外部ユーザーがどのリンクに到達するかを制御するのは困難です。

バージョン7でもこの問題が発生しています。これが関連するかどうかはわかりませんが、あるNext.jsプロジェクトを別のNowデプロイメントのサブフォルダーにエイリアスしています。 したがって、ベースURLはprimer.styleあり、 primer-components.now.sh Next.jsアプリをprimer.style/componentsエイリアスしています。 本番環境では、 primer.style/componentsのインデックスページは正常に機能しますが、 primer.style/components/は404を生成します。

この問題を見つけるには、少し検索する必要がありました。 私はNetlifyで静的デプロイメントを使用しているので、prodの問題ではありませんが、開発（次の7）では、末尾にスラッシュがあるとコンパイルがフリーズするだけで、その理由を理解するのは困難でした。 これ（開発環境で末尾のスラッシュを処理しない）は良いDXではないと思います。

私もこの問題を抱えています、そしてそれは本当に迷惑です、私はそれがすぐに修正されることを願っています。

末尾のスラッシュが必要な場合は、これを行うことができます。 <Link href='/about' as='/about/'><a>about</a></Link>ですが、金曜日/次のルートを使用している場合、これは不可能です。 だから私はあなたが小道具としてtrailingSlashを追加できるフォークを持っています。 お役に立てれば

末尾のスラッシュが必要な場合は、これを行うことができます。 <Link href='/about' as='/about/'><a>about</a></Link>ですが、金曜日/次のルートを使用している場合、これは不可能です。 だから私はあなたが小道具としてtrailingSlashを追加できるフォークを持っています。 お役に立てれば

@aluminick申し訳ありませんが、これを試したところ、

また、＃6664も＃6752もこれらの助けにはなりません。なぜなら、 experimental.exportTrailingSlashはnext export専用であるため、役に立たないからです。

@Janpotによる有望なプルリクエスト＃6421があり

@iamstarkovこの問題の状況はどうなっていますか？ server.jsフック以外の解決策はありますか？

@dryleafステータス：まだ開いています

同様の問題...複数のスラッシュが追加された場合のリダイレクト。 例： https ：

GitHubのURLは関係ありません

@iamstarkovどういう意味かわからない。 しかし、元の投稿を読み直した後は、もっと明確にできたようです。

GitHubのURLは、アプリがNext.jsでビルドされたときにURLが（できれば）どのように機能するかを簡単に示すことを目的としています。 つまり、ユーザーがスラッシュを追加しても、URLは機能するはずです。

nextjs 9のアップデートはありますか？

Nextは初めてですが、この問題で使用している回避策は何ですか？

@iamstarkovこの問題の状況はどうなっていますか？

この問題が約1年間、まったく解決されなかったことにショックを受けました。
Next.jsチームは、これを修正し始めるために他の理由が必要ですか？

URLは、末尾のスラッシュに関係なく機能するはずです。 Web上の任意のサイトを確認してください。

これがNext.jsの範囲外である場合は、Nowでこれを構成する機能を提供してください。
Zeitチームがそのような重大な問題を何年も無視していることに私は本当に混乱しています。

@exentrichこれは、スラッシュなしですべての末尾のスラッシュを同じルートに301リダイレクトするだけで、

now.json ：

"routes": [
    {
      "src": "/(.*)/",
      "status": 301,
      "headers": { "Location": "/$1" }
    },
    ...
]

ただし、これがNext.js自体によって処理されない理由と、チームがこの問題を無視した理由もわかりません。

これは、（作業中の） public/とともに、CRA変換が実行されているのを目にする主な問題です。

@rauchg

@NathanielHillありがとう！
このソリューションを試しましたが、クエリパラメータが削除されています。 たとえば、 /some/?query=1はクエリなしで/someリダイレクトされます。 あなたはそれを修正する方法を知っていますか？

ええ、それは問題のように聞こえます@exentrich

正規表現の周りに暗黙の^と$ラップされていると言われているので、その動作を推測することはできませんでした（つまり、例が一致しません）。 クエリ文字列に独自にアクセスして追加し直す方法があるかもしれません：man_shrugging：頑張ってください

カスタムエクスプレスサーバーとavinoamr / connect-slashesを使用して動作させようとしていますが、同じ問題が発生しているようです

これは確かに大きな問題です。特に/ルートがエラーページをスローし、SEO（Nextの主要な魅力の1つ）を傷つけるからです。

301リダイレクトとカスタムエクスプレスサーバーはすべて、修正ではなくハッキングのようです。 私の場合、カスタムExpressサーバーを使用せずにNextで完全に機能するアプリケーションを構築して

PS：私はNext❤️と一緒に仕事をするのが大好きです

これは確かに大きな問題です。特に/ルートがエラーページをスローし、それがSEOを傷つけるからです。

それはあなたのSEOを傷つけません。 グーグルは末尾のスラッシュを別のページとして扱います。 404を使用しても、サイト内の他の存在しないページよりもSEOに影響を与えることはありません。 その上、末尾のスラッシュでリンクしない限り、グーグルはそもそもそれをクロールしようとはしません。 この問題はまだ有効な問題ですが、皆さんが考えているほど重要ではありません。

@ nik-john @NathanielHill @dkrish @exentrich

301リダイレクトを行うためにExpressサーバーを使用する必要はありません。 あなたの要件に依存しますが、私はカスタムserver.js私のものを満たすことができました。

スラッシュルートと非スラッシュルートで重複コンテンツのペナルティが発生しないため、301リダイレクトもSEOに最適な方法です。

私は❤️Next.jsが大好きですが、この回避策なしでこれを処理することに投票します。

// server.js

const { createServer } = require('http');
const { parse } = require("url");
const next = require("next");

const dev = process.env.NODE_ENV !== 'production'
const port = parseInt(process.env.PORT, 10) || 3000;
const app = next({ dev, quiet: false });
const handle = app.getRequestHandler();

(async () => {
    await app.prepare();
    const server = createServer();

    server.on('request', async (req, res) => {

        const parsedUrl = parse(req.url, true);
        const { pathname, query } = parsedUrl;

        if (pathname.length > 1 && pathname.slice(-1) === "/") {
            console.log('server.js - redirect on "/"...', pathname, query);
            const queryString = await Object.keys(query).map(key => key + '=' + query[key]).join('&');
            res.writeHead(301, { Location: pathname.slice(0, -1) + (queryString ? '?'+ queryString : '') });
            res.end();
        }

        handle(req, res, parsedUrl);

    });

    await server.listen(port);
    console.log(`🚀 Ready on http://localhost:${port}`);

})();

@Janpot

それはあなたのSEOを傷つけません。 グーグルは末尾のスラッシュを別のページとして扱います。 404を使用しても、サイト内の他の存在しないページよりもSEOに影響を与えることはありません。

私はそれがSEOを本質的に特に傷つけないというあなたのポイントを取ります。 ただし、開発者は毎回URL定義を正しく取得する必要があり、人的エラーが発生する可能性があります。 Nextを初めて使用する開発者は、次の（完全に通常の外観の）URLが404ページにつながることを必ずしも知っているとは限りません。 <Link href='/people/'>

成熟したフレームワークは、理想的にはimoのようなヒューマンエラーの影響を受けてはなりません。

その上、末尾のスラッシュでリンクしない限り、グーグルはそもそもそれをクロールしようとはしません。

再び-偶然_へのリンク人々の問題が存在するwww.mysite.com/people/_代わりに_のwww.mysite.com/people_ （ -でも、ほとんどの開発者のユーザーに対してまったく同じように見えるどちらも）を。

これらのシナリオは両方ともSEOに影響を与える可能性があります。

さて、SEOの影響を考慮せずに、URLの意味的な意味もあります-何を_しますか_ _ www.mysite.com/people / _は何を指しますか？ 理想的には、ディレクトリを指しているため、Nextはpages > people > index.jsものをすべて返す必要があります（_www.mysite.com/people_のpages > people.jsは対照的です）が、代わりに何も返しません。これは非常に重要です。ルーティングの動作に高レベルの欠陥があります。

主要なルーティングライブラリには、これに対するいくつかのプロビジョニングがすでにあります-ReactRouterの場合のisExactのように

私はあなたがどこから来ているのか理解していますが、それでもこれは明白な問題であり、ぶつかる必要があると思います

next export場合も、これは完全に避けられません。

誤ってリンクする人の問題があります...

存在しないURLに誤ってリンクするという問題がありますが、なぜ/some/path/は/some/path/dhgfiuwoよりも存在しないのでしょうか。

URLの意味もあります

これは非常に主観的です。私が知る限り、セマンティックの違いを規定する仕様はありません。 URL仕様によると、末尾のスラッシュがある場合とない場合は異なるURLと見なされます。 私は少なくとも7つの異なる有効な行動を考えることができます：

• 内容が完全に異なる場合とない場合
• 404あり、解決なし
• 解決あり、なし404
• なしへのリダイレクトあり
• にリダイレクトせずに
• ありとなしで同じ内容を持ち、正規のポインティングと
• ありとなしで同じ内容を持ち、正規のポインティングなし

これを、 /pages/some-page.jsと/pages/some-page/index.jsいずれか（または両方）を持つ可能性と組み合わせます。

next.jsはこれらすべてのユースケースをサポートする必要がありますか？ デフォルトの動作を選択する必要がありますか？

私はこれに反対していませんが、以前にこれを実装しようとした後、当初の見た目よりもニュアンスが多いと思います。

存在しないURLに誤ってリンクするという問題がありますが、なぜ/ some / path /は/ some / path / dhgfiuwoよりも存在しないのでしょうか？

/some/path/dhgfiuwo場合、人々はdhgfiuwoルートが欠落している可能性があると予想しています。 （たとえば、ユーザーdhgfiuwoがシステムで見つからず、方法users/dhgfiuwoが間違っています。システムにユーザーがいないことは予想されることです。）
ケース/some/path/ -これは他のサイトのデフォルトの動作であるため、人々はこのパスが/some/pathと同じであると期待しています。
したがって、 would/some/path/での障害は、 /some/path/dhgfiuwoよりも存在しません。

他の人がソリューションを投稿しているのを見たので、私のアプローチを共有したいと思いました： https ：

？=に関しては、動的にルーティングされたページのいくつかの改善とサポートをIMOで行う必要がありますが、これはアイデアを示すためだけのものです。

簡単な解決策として、デフォルトの_errorページを置き換えることができます（ @DevSpeakの例のように）。

@DevSpeak 、私はあなたのリポジトリにいくつかの変更をお勧めします：

• 301リダイレクトは避けてください。これらはブラウザによって永続的にキャッシュされ、多くの問題を引き起こす可能性があります。 ほとんどの場合、必要なのは302だけです。
• errorCodeの三部形式は更新できます（先週までドキュメントでは古くなっていました）
• これはサーバー側のみであるため、 if (typeof window === 'undefined') { ... }ラップして、クライアントバンドルからツリーシェイクできます。

Typescriptプロジェクトで使用しているものは次のとおりです（組み込みのエラーページに基づく）：

/pages/_error.tsx （またはTypeScriptタイプを削除して/pages/_error.jsxという名前を付けます）：

import React from 'react';
import Head from 'next/head';
import { NextPageContext } from 'next';

const statusCodes: { [code: number]: string } = {
  400: 'Bad Request',
  404: 'This page could not be found',
  405: 'Method Not Allowed',
  500: 'Internal Server Error'
};

export type ErrorProps = {
  statusCode: number;
  title?: string;
};

/**
 * `Error` component used for handling errors.
 */
export default class Error<P = {}> extends React.Component<P & ErrorProps> {
  static displayName = 'ErrorPage';

  static getInitialProps({
    req,
    res,
    err
  }: NextPageContext): Promise<ErrorProps> | ErrorProps {
    const statusCode =
      res && res.statusCode ? res.statusCode : err ? err.statusCode! : 404;
    if (typeof window === 'undefined') {
      /**
       * Workaround for: https://github.com/zeit/next.js/issues/8913#issuecomment-537632531
       * Test vectors:
       * `/test/test/` -> `/test/test`
       * `/test/////test////` -> `/test/test`
       * `/test//test//?a=1&b=2` -> `/test?a=1&b=2`
       * `/test///#test` -> `/test#test`
       */
      const correctPath = (invalidPath: string) =>
        invalidPath
          .replace(/\/+$/, '')
          .replace(/\/+#/, '#')
          .replace(/\/+\?/, '?')
          .replace(/\/+/g, '/');
      if (req && res && req.url && correctPath(req.url) !== req.url) {
        res.writeHead(302, {
          Location: correctPath(req.url)
        });
        res.end();
      }
      const reqInfo = req
        ? `; Url: ${req.url}; IP: ${req.headers['x-forwarded-for'] ||
            (req.connection && req.connection.remoteAddress)};`
        : '';
      console.log(`Error rendered: ${statusCode}${reqInfo}`);
    }
    return { statusCode };
  }

  render() {
    const { statusCode } = this.props;
    const title =
      this.props.title ||
      statusCodes[statusCode] ||
      'An unexpected error has occurred';

    return (
      <div style={styles.error}>
        <Head>
          <title>
            {statusCode}: {title}
          </title>
        </Head>
        <div>
          <style dangerouslySetInnerHTML={{ __html: 'body { margin: 0 }' }} />
          {statusCode ? <h1 style={styles.h1}>{statusCode}</h1> : null}
          <div style={styles.desc}>
            <h2 style={styles.h2}>{title}.</h2>
          </div>
        </div>
      </div>
    );
  }
}

const styles: { [k: string]: React.CSSProperties } = {
  error: {
    color: '#000',
    background: '#fff',
    fontFamily:
      '-apple-system, BlinkMacSystemFont, Roboto, "Segoe UI", "Fira Sans", Avenir, "Helvetica Neue", "Lucida Grande", sans-serif',
    height: '100vh',
    textAlign: 'center',
    display: 'flex',
    flexDirection: 'column',
    alignItems: 'center',
    justifyContent: 'center'
  },

  desc: {
    display: 'inline-block',
    textAlign: 'left',
    lineHeight: '49px',
    height: '49px',
    verticalAlign: 'middle'
  },

  h1: {
    display: 'inline-block',
    borderRight: '1px solid rgba(0, 0, 0,.3)',
    margin: 0,
    marginRight: '20px',
    padding: '10px 23px 10px 0',
    fontSize: '24px',
    fontWeight: 500,
    verticalAlign: 'top'
  },

  h2: {
    fontSize: '14px',
    fontWeight: 'normal',
    lineHeight: 'inherit',
    margin: 0,
    padding: 0
  }
};

これは、ページがヒットしたときにもエラーをログに記録するため、ログを確認してリンクやその他の問題を修正できることに注意してください。

@ DevSpeak @ bitjsonご提案ありがとうございます。 これは確かにこれを実行する1つの方法であり、問​​題を非常にうまく解決します。 しかし、 _error.jsxは元々、ルーティングロジックを格納するのではなく、_errors_を処理することを目的としていることを考えると、このコードをすべて持っていると、ハッキーで非常に宣言的です。 すべてのユーザーがすべてのコードベースでこれを行うことを期待することは必須ではありません-これは箱から出して来るはずです。 =この条件は、React Routerのようにオプトアウトするオプションを使用して、ルーティングロジックに組み込む必要があると思います。

@NathanielHill

これは次の輸出の場合にも完全に避けられません

待ってください-ドキュメントを読んで、末尾のスラッシュ条件を処理するための特定のコードがあることを理解しました。

ページはhtmlファイルとしてエクスポートされます。つまり、/ aboutは/about.htmlになります。

ページをindex.htmlファイルとしてエクスポートするようにNext.jsを構成し、末尾にスラッシュを付けることができます。つまり、/ aboutは/about/index.htmlになり、/ about /を介してルーティングできます。 これは、Next.js 9より前のデフォルトの動作でした。次のnext.config.jsを使用して、この動作に戻すことができます。

// next.config.js
module.exports = {
  exportTrailingSlash: true,
}

これがnext exportを介した静的HTMLエクスポートのオプションではない場合でも、Nextがこの（驚くべき）機能をサポートしているという理由だけで、他のモードが苦しむ必要があるという論理には同意しません（私はそうしません）使用統計を知っていますが、特にこれがそのような一般的なユースケースであることがわかっている場合は、サーバーレスではなく通常のサーバー付きモードを使用する人が多いと思います）

参考：興味があるかもしれないRFCがありますhttps://github.com/zeit/next.js/issues/9081

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: "/:path*/",
        destination: "/:path",
        statusCode: 301
      }
    ];
  }
};

@Janpot Love next.config.jsリダイレクトを設定する必要があるため、これは依然として不可欠です。または、正規表現を使用して、 @ bitjsonのようなすべてのケースをキャッチすることも

          .replace(/\/+$/, '')
          .replace(/\/+#/, '#')
          .replace(/\/+\?/, '?')
          .replace(/\/+/g, '/')

いずれの場合も、コアチームがこのRFCを優先している場合は、さらに一歩進んで、組み込みの_config_にして、そのように

// next.config.js
module.exports = {
  ignoreStrictRoutes: false, // default value: true
};

全体として、これは大きな前進だと思います-良いもの@Timer !! 🔥

@ nik-john "/:path*/"指定したパスはすべてをキャッチする必要があります（ :pathは単一のセグメントをキャッチし、 *は0からn個のインスタンスをキャッチします）。

@Janpotああ私の悪い🤦‍♂私たちはまた、その正規表現の末尾のクエリパラメータを考慮する必要があると思います

また、私はまだ2番目の部分を支持しています：

いずれの場合も、コアチームがこのRFCを優先している場合は、さらに一歩進んで、オプトアウトできる組み込みの構成にすることを強くお勧めします。

// next.config.js
module.exports = {
  ignoreStrictRoutes: false, // default value: true
};

カスタムサーバーを使用していて、厳密なルートを無視したい場合は、リダイレクトを行う代わりにカスタムルートハンドラーを使用することもできます。

app.render(req, res, urlWithoutTrailingSlash, query);

このようにして、 /pathと/path/両方をサポートし、同じページに解決することができます。

Oauthフェデレーションプロバイダーは、多くの場合、末尾のスラッシュを必要とするため、この動作により、単純なフローが非常に複雑になります。 この動作を実装する際の技術的な課題は何ですか？ それとも、これは次からの設計上の決定ですか？

このスレッドではこれまで言及されていませんが、Nowでデプロイした後はこの問題は発生していません。 now devテストした場合にのみローカルで発生しています。

const removeTrailingSlashes = (req, res, expressNext) => {
  if (req.path.substr(-1) === '/' && req.path.length > 1) {
    const query = req.url.slice(req.path.length);
    res.redirect(301, req.path.slice(0, -1) + query);
  } else {
    expressNext();
  }
};

これをstackoverflowから取得し、完全に機能しました。 このソリューションはExpressで機能します。

@GaneshKathar Expressを使用していない

これについては同意できないと思います。構成可能である必要があります。

私は実際には常に末尾のスラッシュが必要です。すべてのページが末尾のスラッシュで終わる場合、相対URLを推論する方が簡単です。

例えばそれは、という意味になりません/about/index.tsxで/aboutの代わりに/about/スラッシュを付けずに、今その次を期待、しかし理解できます。 すべてのページがスラッシュで終わる場合、将来的にページにサブページを含めることができるようになります。これは、ページにとってより拡張可能な方法だと思います。

/about/index.tsxファイル内に相対リンクを作成するのは面倒です。 リンクを./mysubpage/すると、代わりにサイトのルートを指します。 これにより、サブページの名前を変更できなくなります。 相対リンクも編集する必要があるため、名前を変更できるページでディレクトリ/about/作成することはできません。

また、 wget -rサイトは、常に末尾にスラッシュがあり、index.htmlファイルを生成するという賢明な結果を生成します。

ただし、この設定を変更すると、すべてのサイトで末尾以外のスラッシュが必要になるため、変更が大幅に中断されます。そのため、構成可能である必要があります。

バージョン9を使用していますが、この問題はまだ解決されていません

next.config.js次のようなものを使用して、それを機能させることができました。

exportPathMap: async function() {
  const paths = {
    '/': { page: '/' },
    '/authors/index.html': { page: '/authors' },
  };

  return paths;
},

/authorsアクセスすると、302がlocationを/authors/ます。 http-serveでテストしていますが、この動作がサーバー固有であるかどうかはわかりません。

この問題に直面したとき、私はこの解決策を思いつきました

私の_error.jsページで

Error.getInitialProps = ({ res, err, asPath }) => {
    const statusCode = res ? res.statusCode : err ? err.statusCode : 404;

    const checkForTrailingSlashes = () => {
        if (asPath.match(/\/$/)) { // check if the path ends with trailing slash
            const withoutTrailingSlash = asPath.substr(0, asPath.length - 1);
            if (res) {
                res.writeHead(302, {
                    Location: withoutTrailingSlash
                })
                res.end()
            } else {
                Router.push(withoutTrailingSlash)
            }
        }
    }

    if (statusCode && statusCode === 404) {
        checkForTrailingSlashes();
    } else {
        // 
    }
    return { statusCode };
}

それは問題を克服するための良い方法ですか？

これはどう？

pages / _app.jsx

`` `import React from'react ';
'next / app'からアプリをインポートします。

デフォルトクラスのエクスポートMyAppはAppを拡張します{
与える（） {
const {Component、pageProps、router：{asPath}} = this.props;

// Next.js currently does not allow trailing slash in a route.
// This is a client side redirect in case trailing slash occurs.
if (asPath.length > 1 && asPath.endsWith('/')) {
  const urlWithoutEndingSlash = asPath.replace(/\/*$/gim, '');

  if (typeof window !== 'undefined') {
    window.location.replace(urlWithoutEndingSlash);
  }
  return null;
}

return <Component {...pageProps} />;

}
}
`` `

@cnblackxp提案をありがとう。 それは私を助けました。 非トレーリング404のデフォルトの動作を維持するために、これを実装した方法は次のとおりです（つまり、デフォルトのError実装を単に再エクスポートしています）。

import Error from "next/error";
import Router from "next/router";

export default Error;

Error.getInitialProps = ({ res, err, asPath }) => {
  const statusCode = res ? res.statusCode : err ? err.statusCode : 404;

  if (statusCode && statusCode === 404) {
    if (asPath.match(/\/$/)) {
      const withoutTrailingSlash = asPath.substr(0, asPath.length - 1);
      if (res) {
        res.writeHead(302, {
          Location: withoutTrailingSlash
        });
        res.end();
      } else {
        Router.push(withoutTrailingSlash);
      }
    }
  }

  return { statusCode };
};

うん、他に何も決まっていない限り、

@AlexSapoznikovの回避策の小さな改善：

  render() {
    const { Component, pageProps, router: { asPath } } = this.props;

    // Next.js currently does not allow trailing slash in a route.
    // This is a client side redirect in case trailing slash occurs.
    if (pageProps.statusCode === 404 && asPath.length > 1 && asPath.endsWith('/')) {

ここでの唯一の違いは、ステータスコードが404であることを確認することです。リダイレクトのためにサーバー上で常にレンダリングされていた動的ルートにLinkを使用すると問題が発生しました。 クライアント側のルーティングを機能させたい場合は、リンクhrefプロップに末尾のスラッシュを追加することはできませんが、この場合はリダイレクトしないようにする必要があります。

エラーコンポーネントで回避策を実装する際の問題は、開発中に通知エラーがスローされ、気になることです。 以前のクライアント側リダイレクトに対するいくつかの改善：

改善されたのは、クライアント側でnext / routerを使用し、URLの置換がリロードなしで行われるようになったことです。

pages / _app.jsx

import App from 'next/app';
import Router from 'next/router';

export default class MyApp extends App {
  render() {
    const { Component, pageProps, router: { asPath, route } } = this.props;

    // Next.js currently does not allow trailing slash in a route.
    // This is a client side redirect in case trailing slash occurs.
    if (pageProps.statusCode === 404 && asPath.length > 1 && asPath.endsWith('/')) {
      const routeWithoutEndingSlash = route.replace(/\/*$/gim, '');
      const asPathWithoutEndingSlash = asPath.replace(/\/*$/gim, '');

      if (typeof window !== 'undefined') {
        Router.replace(routeWithoutEndingSlash, asPathWithoutEndingSlash);
      }
      return null;
    }

    return <Component {...pageProps} />;
  }
}

404修正のための@mbrowneにも感謝します:)

@cansinのソリューションを採用し、クエリパラメータを処理する機能を追加しました

MyError.getInitialProps = async ({ res, err, asPath }) => {
  // Capture 404 of pages with traling slash and redirect them
  const statusCode = res 
    ? res.statusCode
    : (err ? err.statusCode : 404);

  if (statusCode && statusCode === 404) {
    const [path, query = ''] = asPath.split('?');                                                                                                                                                                                             
    if (path.match(/\/$/)) {
      const withoutTrailingSlash = path.substr(0, path.length - 1); 
      if (res) {
        res.writeHead(302, {
          Location: `${withoutTrailingSlash}${query ? `?${query}` : ''}`,
        }); 
        res.end();
      } else {
        Router.push(`${withoutTrailingSlash}${query ? `?${query}` : ''}`);
      }   
    }   
  }

@pinpointcoderは、末尾にスラッシュがあり、クエリパラメータが同時に発生するURLの例を提供できますか？ あなたは/blog/?123の線に沿って考えていますか？

上記の回避策のいくつかをみんなに感謝します。 彼らが働いていました！

ただし、Nextのチームからこの問題を修正する公式の方法はありますか？ この問題は何年も前からあります。

次のエクスポートでは、ディレクトリページに末尾のスラッシュが表示されません

@pinpointcoderは、末尾にスラッシュがあり、クエリパラメータが同時に発生するURLの例を提供できますか？ あなたは/blog/?123の線に沿って考えていますか？

@coodoo彼ではありませんが、はい、残念ながらこれは

正規URLに現在末尾のスラッシュが含まれている大量のブログ投稿を移行しようとしているので、これは今の私のお尻の大きな痛みです。

これを処理するためにカスタムサーバーを実装することにしましたが、それは簡単で、next.jsのファイルベースのルーティングシステムを引き続き使用できます。 そうすれば、next.jsが認識するURLを書き換えても、実際のURLの末尾にはスラッシュが付いたままになります。

const { createServer } = require('http')
const { parse } = require('url')
const next = require('next')
const conf = require('./next.config.js')

const PORT = process.env.PORT || 5000

const dev = process.env.NODE_ENV !== 'production'
const app = next({ dev, conf })
const handle = app.getRequestHandler()

app.prepare().then(() => {
    createServer((req, res) => {
        // If there is a slash at the end of the URL, remove it before sending it to the handle() function.
        // This is a workaround for https://github.com/zeit/next.js/issues/5214
        const url =
            req.url !== '/' && req.url.endsWith('/')
                ? req.url.slice(0, -1)
                : req.url
        // Be sure to pass `true` as the second argument to `url.parse`.
        // This tells it to parse the query portion of the URL.
        const parsedUrl = parse(url, true)

        handle(req, res, parsedUrl)
    }).listen(PORT, err => {
        if (err) throw err
        console.log(`> Ready on http://localhost:${PORT}`)
    })
})

https://nextjs.org/docs/advanced-features/custom-serverを参照して

@mbrowne実際には、カスタムサーバーを使用する理由はたくさんありますが、これまで実装できなかった主な理由は、自動静的最適化が失われることです。 静的ルートを手動で指定できるかどうか知っていますか？

現時点では、アプリの自動静的最適化は必要ないため、調査していません。

私もカスタムサーバーを使用していますが、変更された（スラッシュなしで）URLをhandleに渡すと、SSRはクライアント側とは異なるURLを認識します。
私はnextルーターが、これらの厄介なハッキングなしにURLを先頭のスラッシュと一致させることを好みます。

2020年とこのバグはまだ発生しています。 信じられない

これは悪いバグであり、本当に修正する必要があります。 /products機能しますが、 /products/は機能しません。 このリンクで

<Link href="/products">
  <a>Products</a>
</Link>

私は得る

index.js:1 Warning: Prop `href` did not match. Server: "/products" Client: "/products/"

ただし、リンクを/products/にポイントし、リンクにアクセスして、開発中にページを更新すると、404が表示されます。これは非常に苦痛な開発経験です。

この問題は1。5年前に最初に報告されました。 公式の修正をお願いできますか？ それは9.3.4にまだ存在しています。

SEOの理由から、コンテンツを表示する代わりに、末尾以外のスラッシュURLにリダイレクトしました。

app.prepare().then(() => {
  createServer((req, res) => {
    if (req.url !== '/' && req.url.endsWith('/')) {
      res.writeHead(301, { Location: req.url.slice(0, -1) })
      res.end()
    }
    handle(req, res, parse(req.url, true))
  }).listen(PORT, err => {
    if (err) throw err
    console.log(`> Ready on http://localhost:${PORT}`)
  })
})

SEOの場合、 rel="canonical"が役立つ場合がありますが、それでもこの404の問題を修正する必要があります。

これは悪いバグであり、本当に修正する必要があります。 /products機能しますが、 /products/は機能しません。 このリンクで

<Link href="/products">
  <a>Products</a>
</Link>

私は得る

index.js:1 Warning: Prop `href` did not match. Server: "/products" Client: "/products/"

ただし、リンクを/products/にポイントし、リンクにアクセスして、開発中にページを更新すると、404が表示されます。これは非常に苦痛な開発経験です。

この問題は1。5年前に最初に報告されました。 公式の修正をお願いできますか？ それは9.3.4にまだ存在しています。

私も現在この問題を抱えています。

これが私がそれを修正した方法です、 https： //medium.com/@thisisayush/handling -404-trailing-slash-error-in-nextjs-f8844545afe3

これが私がそれを修正した方法です、 https： //medium.com/@thisisayush/handling -404-trailing-slash-error-in-nextjs-f8844545afe3

ローカルで開発する場合、これにはカスタムサーバーが必要であり、必須ではありませんが、ありがとうございます。

@timneutkensこの問題の修正を開発スケジュールに組み込むことができる可能性はありますか？

さらに重要なことに、リダイレクトソリューションは、本番環境でスラッシュを削除するのではなく、スラッシュを追加するように既に設定されているサイトを維持しているユーザーには機能しません。 フレームワークがこの選択を恣意的に指示するべきではないと思います。

@AlexSapoznikovのソリューションは、Netlifyでうまく機能しました（デフォルトで末尾にスラッシュが追加されます）。 クエリパラメータのサポートを追加する高度なバージョンは次のとおりです。

import App from "next/app";

export default class MyApp extends App {
  render() {
    const { Component, pageProps, router, router: { asPath } } = this.props;

    // Next.js currently does not allow trailing slash in a route, but Netlify appends trailing slashes. This is a
    // client side redirect in case trailing slash occurs. See https://github.com/zeit/next.js/issues/5214 for details
    if (asPath && asPath.length > 1) {
      const [path, query = ""] = asPath.split("?");
      if (path.endsWith("/")) {
        const asPathWithoutTrailingSlash = path.replace(/\/*$/gim, "") + (query ? `?${query}` : "");
        if (typeof window !== "undefined") {
          router.replace(asPathWithoutTrailingSlash, undefined, { shallow: true });
          return null;
        }
      }
    }

    return <Component {...pageProps} />;
  }
}

他のSDKやプラットフォームでのソフトウェア開発の経験はありますが、私はNext JSの初心者なので、お詫び申し上げます。

この「バグ」は私を最も驚かせたと思います。 私にとって、それは「驚き最小の原則」に違反していました。 index.tsxを/ pages / about /フォルダーに配置したので、/ about /と/ aboutが同じように機能することを期待していました。

私は1990年代後半にサーバーにHTMLFTPを使用してWebサイトを作成し始め、その後PHPとApache、そして最終的にはJavaサーバーに移行しました。 今はモバイルアプリを専門としています。 この動作がデフォルトではなく、開発サーバーで修正するためにカスタムサーバーページを作成する必要があるのは、私には奇妙に感じます。

静的エクスポートを実行する予定なので、カスタムサーバーを作成しなくても、本番環境には表示されません。 ただし、開発とデバッグは少し面倒になります。

これを修正する「次の開発」フラグを取得して、怠惰な開発者が開発/デバッグ時間のためだけに追加のルーティングロジックを作成する必要がないようにすることはできますか？

ありがとう！

ps：はい、 /aboutと/about/が完全に異なるURLであることを私は知っています。 index.tsxファイルを/pages/about/フォルダー内に置くと、本当に混乱しました。このファイルは/aboutパスでのみ機能し、 /about/では機能しないことが/about/ 。 それが逆だったとしても、私はそれほど驚かないでしょう。

pps： /about/を指す<Link></Link>コンポーネントがあり、期待どおりに機能する場合は、さらに混乱しました。 次に、ブラウザで更新を押すと、URLが変更されていなくても、すぐに404秒になります。 それは非常に驚くべきことでした。 ：-NS

しかし、待ってください、それは悪化します！ _error.js内にカスタムcheckForTrailingSlash関数を追加しました。これにより、末尾のスラッシュが削除され、リダイレクトされます。 これは、（最終的に）カスタム404ページを追加し、カスタム404ページを使用すると、Next.jsがError完全にバイパスすることがわかるまでしばらくの間問題なく機能しました。 これは、 Error.getInitialProps内のカスタムロジックが機能しなくなることを意味します-末尾のスラッシュのチェックを含みます。

カスタムサーバーはまだ可能性がないので、他の人が言及した_app.jsソリューションを試してみようと思います。

@AlexSapoznikovのソリューションは、Netlifyでうまく機能しました（デフォルトで末尾にスラッシュが追加されます）。 クエリパラメータのサポートを追加する高度なバージョンは次のとおりです。

import App from "next/app";

export default class MyApp extends App {
  render() {
    const { Component, pageProps, router, router: { asPath } } = this.props;

    // Next.js currently does not allow trailing slash in a route, but Netlify appends trailing slashes. This is a
    // client side redirect in case trailing slash occurs. See https://github.com/zeit/next.js/issues/5214 for details
    if (asPath && asPath.length > 1) {
      const [path, query = ""] = asPath.split("?");
      if (path.endsWith("/")) {
        const asPathWithoutTrailingSlash = path.replace(/\/*$/gim, "") + (query ? `?${query}` : "");
        if (typeof window !== "undefined") {
          router.replace(asPathWithoutTrailingSlash, undefined, { shallow: true });
          return null;
        }
      }
    }

    return <Component {...pageProps} />;
  }
}

コードサンプルに重大なエラーがあります。クエリ文字列だけをasPathとしてNext.jsに渡そうとするため、クエリパラメータを使用してインデックスルートにリクエストするとエラーがスローされます。

これはそれを修正します：

  if (asPath && asPath.length > 1) {
    const [path, query = ''] = asPath.split('?');
    if (path.endsWith('/') && path.length > 1) {
      const asPathWithoutTrailingSlash =
        path.replace(/\/*$/gim, '') + (query ? `?${query}` : '');
      if (typeof window !== 'undefined') {
        router.replace(asPathWithoutTrailingSlash, undefined, {
          shallow: true,
        });
        return null;
      }
    }
  }

これをSSRで機能させるには、 @ pjawsおよび@AlexSapoznikovソリューションに以下を追加する必要がありました。

  static async getInitialProps({ Component, ctx, router }) {
    /* Fixes the trailing-slash-404 bug for server-side rendering. */
    const { asPath } = router;
    if (asPath && asPath.length > 1) {
      const [path, query = ""] = asPath.split("?");
      if (path.endsWith("/") && path.length > 1) {
        const asPathWithoutTrailingSlash =
          path.replace(/\/*$/gim, "") + (query ? `?${query}` : "");
        if (ctx.res) {
          ctx.res.writeHead(301, {
            Location: asPathWithoutTrailingSlash,
          });
          ctx.res.end();
        }
      }
    }
    return {
      pageProps: Component.getInitialProps
        ? await Component.getInitialProps(ctx)
        : {},
    };
  }

おそらく、この機能をSSRとCSRの両方で機能する関数に一般化し、両方の場所（ getInitialPropsとrender ）で呼び出すことをお勧めします。

に

これは修正されますが、タイトルが間違っています。 うーん

@AlexSapoznikov @pjaws

あなたの解決策は私たちを無限ループに陥らせます：

  if (asPath && asPath.length > 1) {
    const [path, query = ''] = asPath.split('?');
    if (path.endsWith('/') && path.length > 1) {
      const asPathWithoutTrailingSlash =
        path.replace(/\/*$/gim, '') + (query ? `?${query}` : '');
      if (typeof window !== 'undefined') {
        router.replace(asPathWithoutTrailingSlash, undefined, {
          shallow: true,
        });
        return null;
      }
    }
  }

環境

制御できない理由により、 next.config.js exportTrailingSlashオプションを使用する必要があります。

別のページへのリンクが必要ですが、リンクを/somepage?param=whateverます。

次のリンクがこれを/somepage/?param=whatever変換し、ページが見つからないようです。

上記のソリューションを使用してparamsの問題を解決しますが、 /somepage/ようなデプロイされたページに移動すると、無限ループに入ります。

@ronyehはここで本当に良い点を

これをSSRで機能させるには、 @ pjawsおよび@AlexSapoznikovソリューションに以下を追加する必要がありました。

  static async getInitialProps({ Component, ctx, router }) {
    /* Fixes the trailing-slash-404 bug for server-side rendering. */
    const { asPath } = router;
    if (asPath && asPath.length > 1) {
      const [path, query = ""] = asPath.split("?");
      if (path.endsWith("/") && path.length > 1) {
        const asPathWithoutTrailingSlash =
          path.replace(/\/*$/gim, "") + (query ? `?${query}` : "");
        if (ctx.res) {
          ctx.res.writeHead(301, {
            Location: asPathWithoutTrailingSlash,
          });
          ctx.res.end();
        }
      }
    }
    return {
      pageProps: Component.getInitialProps
        ? await Component.getInitialProps(ctx)
        : {},
    };
  }

おそらく、この機能をSSRとCSRの両方で機能する関数に一般化し、両方の場所（ getInitialPropsとrender ）で呼び出すことをお勧めします。

これはgetServerSidePropsのあるページで機能し、末尾にスラッシュが付いたURLは404なしで同じページを返すようになりました。
しかし、グリッチが1つあります。動的ルートとgetStaticPathsを使用するページがほとんどないため、getServerSidePropsを使用できないため、これらの動的ルートを末尾のスラッシュで参照すると、最初に404が返され、次にページにリダイレクトされます。 。

/ api / testフォルダーを使用しています

• pages / api / test.tsx
• pages / api / test / [id] .tsx

それはのために働く

• GET / api / test
• GET / api / test / 123
• GET / api / test / 123 /

そして私はこれが機能しないことを発見しました

• GET / api / test /

これが関連する問題かどうかわからない
P / D exportTrailingSlash = trueはそれを解決しません

これは非常に古い問題ですが、長い間対処されていない理由はありますか？

何が機能していないのかわかりません。

私の控えめな表現は、要件は次のとおりです。

| | exportTrailingSlash：false | exportTrailingSlash：true |
| -------------------------- | ----------------------- ----- | --------------------------- |
| URLは/で終わります| 動作しないはずです| 動作するはずです|
| URLは/で終わらない| 動作するはずです| 動作しないはずです|

これは期待どおりに機能します。

• ローカルではexportTrailingSlash: falseを使用します
• デプロイ（本番ビルド）の場合、 exportTrailingSlash: trueを使用し、nginxはurl/をurl/index.html変換します

@ andrescabana86で確認できることから、これは機能しないはずの場所で機能します。 GET /api/test/123/に対して、 GET /api/test/は機能せず、機能しないはずです。

@Izhaki私は両方を試し、prodにデプロイしました...そして私にとっては機能していません

• GET / api / test /

そして私はexportTrailingSlash: true

必要に応じて公開リポジトリを作成してみることができます。途中で何かを忘れた可能性があります。

あなたの答えをありがとう

@ andrescabana86ここでパブリックリポジトリがどの程度役立つかはわかりません。これは、デプロイ先のサーバーの構成である可能性があります。

package.jsonこのスクリプトを使用して、本番ビルド（ exportTrailingSlash: trueを使用）をローカルでテストしています。

"serve:out": "docker run --rm -v $(pwd)/out:/static -p 5000:80 flashspys/nginx-static"

ブラウザでhttp://localhost:5000/api/test/アクセスできるかどうか、お知らせください。

（ $(pwd)はMac / Linux上にあることに注意してください-Windowsについてはこれを参照してください）

@Izhaki問題は、（最初​​のレポートが示唆しているように）「正当なページのリンクの末尾のスラッシュはクライアント側のナビゲーションでは機能しますが、バンドルが見つからず、ハードリフレッシュ（ssr）で404になる」という事実に関するものでした。 そのため、クライアント側のルート変更の動作とハードリフレッシュの動作の間に不一致がありました。 Next.jsの最新バージョンで問題が解決するかどうかはわかりません。 テストしたら、ここに報告できます。

9.4.1とexportTrailingSlash: trueテストしました。

http://localhost:6500/admin/に移動すると、ローカルで開発するときに404が返されます。

ただし、エクスポートする場合も同じパスが機能します。

exportTrailingSlashは、これが_exports_専用であることを示唆していることに注意してください。

私たちがしていることは使用です：

exportTrailingSlash: process.env.NODE_ENV === 'production'

つまり、ローカルで開発する場合、物事は意図したとおりに機能します。 また、展開時に（エクスポートを介して）適切に機能します。

それはこれに対する正しくて実行可能な解決策ではありませんか？

URLが開発では機能しないが本番では機能する場合、それは驚き最小の原則に反すると思いませんか？ これはまだバグと見なされるべきだと思います。

^そうは言っても、以前の本番環境では、ページの更新とrouter.pushイベントの間に競合する動作があったと確信しています。 それがまだ当てはまるかどうかはわかりません。

@ andrescabana86 @Izhaki exportTrailingSlashはこれとは無関係です。 このオプションは、Next.jsアプリケーションの静的エクスポートに関連しています。 trueの場合、 example/index.htmlが生成され、falseの場合、 example.htmlが生成されます。 私の理解では、 exportTrailingSlashは開発モードとは何の関係もありません。

混乱の原因の1つは、 exportTrailingSlashがある場合、next.jsがリンクの末尾にスラッシュを追加することだと思います。 これは開発でも発生しますが、これを実行する必要があるかどうかわかりませんか？ しかしとにかく、これはexample/index.html対example.htmlだけではありません-リンクも変更する必要があります。

URLが開発では機能しないが本番では機能する場合、それは驚き最小の原則に反すると思いませんか？ これはまだバグと見なされるべきだと思います。

私は間違っているかもしれませんが、exportTrailingSlashオプションは、URLが/somethingときに/something.htmlを提供するように構成されていないnginxサーバー用/something 。

これは、ローカル開発に使用される次のサーバーには当てはまりません。 したがって、何が機能し、何が機能しないかは、アプリに提供されるものによって異なります。

あなたは時にある場合行うことができますexportTrailingSlash真である（これは行いますが、次のサーバには、末尾にスラッシュで終わるルートをサポートする必要がありますexportでexportTrailingSlashやや無関係）。

FWIWこれはすでに取り組んでいます＃13333

私は経験豊富なコーダーではなく、主に複数ページのランディングにNext.jsを使用しています。 どうやら、私はその効果に気づかずに、ほとんどいつも次の回避策を使用してきました。 これがその簡略版です：

// In your server.js
server.get('/:id', (req, res) => {
  const actualPage = `/${req.params.id}`
  app.render(req, res, actualPage)
})

私の場合、追加の静的URLプレフィックスなどをサポートするために使用しているため、コードは少し複雑です。しかし、この削除されたバージョンは、 exportTrailingSlashに関係なく、説明した問題に対して問題なく機能しているようです。設定とそのLinkの影響。 たとえば、URL /aboutと/about/問題なく機能します。

現在の形式では、基本的にNext.jsのネイティブルーティングを模倣しています。 欠点は：それはカスタム必要ですserver.js 、例えば（追加の「サブフォルダ」で）、そして手動で「より深く」のURLのためにそれをサポートする必要があります/company/about/ 。 しかし、プロジェクトでカスタムserver.jsをすでに使用している人にとっては、比較的簡単な解決策のようです。

これをSSRで機能させるには、 @ pjawsおよび@AlexSapoznikovソリューションに以下を追加する必要がありました。

  static async getInitialProps({ Component, ctx, router }) {
    /* Fixes the trailing-slash-404 bug for server-side rendering. */
    const { asPath } = router;
    if (asPath && asPath.length > 1) {
      const [path, query = ""] = asPath.split("?");
      if (path.endsWith("/") && path.length > 1) {
        const asPathWithoutTrailingSlash =
          path.replace(/\/*$/gim, "") + (query ? `?${query}` : "");
        if (ctx.res) {
          ctx.res.writeHead(301, {
            Location: asPathWithoutTrailingSlash,
          });
          ctx.res.end();
        }
      }
    }
    return {
      pageProps: Component.getInitialProps
        ? await Component.getInitialProps(ctx)
        : {},
    };
  }

おそらく、この機能をSSRとCSRの両方で機能する関数に一般化し、両方の場所（ getInitialPropsとrender ）で呼び出すことをお勧めします。

これはgetServerSidePropsのあるページで機能し、末尾にスラッシュが付いたURLは404なしで同じページを返すようになりました。
しかし、グリッチが1つあります。動的ルートとgetStaticPathsを使用するページがほとんどないため、getServerSidePropsを使用できないため、これらの動的ルートを末尾のスラッシュで参照すると、最初に404が返され、次にページにリダイレクトされます。 。

@gauravkrpこれは実際には非常に重要な追加です。 @ AlexSapoznikovソリューションは実際にはページの404をGoogleに返すためです（リダイレクトはクライアントで発生するため）。 私たちの多くがそもそもNext.jsを使用している主な理由はSEOだと思います。

また、これをgetInitialProps入れるだけでうまくいくはずであり、この時点ではmain関数内の部分は不要だと思います。 ここでの主な注意点は、これを使用すると自動静的最適化が失われることです。ただし、おそらく404の束よりも優れています。

いくつかの共有のために...

私のプロジェクトはExpress + Next.jsです。
express 4.17.1
next 9.4.5-canary.7

開発時

動的ランタイム

// next.config.js
module.exports = {
  exportTrailingSlash: false,
};

// app.js
const Next = require('next').default;
const NextApp = Next({ dev });
const NextHandler = NextApp.getRequestHandler();
NextApp.prepare();
app.get('*', (req, res) => NextHandler(req, res));

生産時

静的エクスポート
next buildとnext export -o dist/

// next.config.js
module.exports = {
  exportTrailingSlash: true,
};

// app.js
app.use('/_next', express.static('dist/_next', { etag: true, index: false, maxAge: '365d', redirect: false, dotfiles: 'ignore' }));
app.use('/fonts', express.static('dist/fonts', { etag: true, index: false, maxAge: '365d', redirect: false, dotfiles: 'ignore' }));
app.use('/img', express.static('dist/img', { etag: true, index: false, maxAge: '365d', redirect: false, dotfiles: 'ignore' }));
app.use(express.static('./dist', { index: ['index.html'] }));
app.use((req, res) => {
  res.Redirect('/404'); // <- Express will auto handle both /404 or /404/
});

結論は

クライアントアプリをクリックしてリダイレクトしても問題ありませんが、
また、ハードリフレッシュはstatic routeます。

ただし、 dynamic routeでハードリフレッシュすると404になります。
/album/[id].jsxや/album/123 、
したがって、次のメカニズムを使用してこの問題を修正することを楽しみにしています。

例えば
/album/123で404をヒットすると、
サーバーは引き続きHTMLコンテンツを提供する必要があります。
ブラウザは問題なくページをロードし続けます、
Next.jsが起動すると、 next/routerが自動的に処理します。

本番環境でこの問題の一時的な解決策はありますか？

これを修正する機能を1日ほど着陸させようとしています。

本番環境でこの問題の一時的な解決策はありますか？

このスレッドにはたくさんありますが、私は現在@gauravkrpが最近投稿したものを使用しており、それは私にとってうまく機能しています。

ここでPRを追跡できます：＃13333

これはnext@^9.4.5-canary.17解決されました！

機能がカナリアからマスターに到達するまでにどのくらい時間がかかりますか？

これはnext@^9.4.5-canary.17解決されました！

そして、それはどの程度正確に解決されますか？ 末尾のスラッシュを削除するだけですか？ 私のアクセス「場合www.site.com/help/ 」私はにリダイレクト：「 www.site.com/help 」、我々はスラッシュを終了去るためにそこに選ぶ選択肢を持つことができますか？ 「 www.site.com/help/ 」または「 www.site.com/help 」にアクセスすると、「/」が終了するか、リダイレクトされるか、最後に「/」が追加され、「 www.site.com/help/ 」になります。

@Valnexusは＃

module.exports = {
  experimental: {
    trailingSlash: true
  }
}

機能がカナリアからマスターに到達するまでにどのくらい時間がかかりますか？

準備ができたら。 解決されている処理にはまだエッジケースがあります。 それらが修正されると、安定することができます。

@timneutkens @Janpot

私は、最新の次のカナリア（9.4.5-canary.27）を試してみましたが、私は作成したときにtestページを、私はアクセスwww.example/test/それはにリダイレクトwww.example/test
どちらの場合も同じように動作するはずだと思います。

www.example/test/にアクセスするときは、 www.example/test/ままにする必要があります。
www.example/testにアクセスするときは、 www.example/testままにする必要があります。
Nuxt.jsでテストしますが、上記と同じ動作をします。

どちらの場合も同じように動作するはずだと思います。

リダイレクトの理由は、検索エンジンに重複するコンテンツが表示されないようにするためです。 あなたの正確なユースケースは何ですか？

まだ安定版にマージされていないのに、なぜクローズドな問題なのかわかりません。 私が正しく理解していれば、それは今のところカナリアリリースでのみ修正されていますよね？

カナリアですぐに使用できるため、関連するプルリクエストが到着すると問題はクローズされます。 この機能が必要な場合は、カナリアチャンネルにアップグレードしてください。

いいですね。 ありがとう、@ Timer！

@Janpot https://github.com/issues/とhttps://github.com/issuesがリダイレクトなしで同じ動作にアクセスできることを確認しました。

https://twitter.com/explore/とhttps://twitter.com/explore 、これも。

検索エンジンに問題がある場合、GithubとTwitterで修正されなかったのはなぜですか？
これはどのWebサイトでもデフォルトの動作だと思います。

特定のユースケースはありません。そのように機能するはずだというのが私の意見です。

検索エンジンに問題がある場合、GithubとTwitterで修正されなかったのはなぜですか？

@armspktそれを解決するいくつかの方法があるので、それは問題ではありません。 たとえば、Twitterは<link rel="canonical">属性を使用して、検索ボットにクロールするページと他のバージョンを重複としてマークする必要があることを通知します。

したがって、リダイレクトは、WebサイトでSEOを作成するための実行可能な方法です。 あなたはここでより多くの情報を読むことができ

@zisermanそれを解決する方法がいくつかある場合は、ユーザーエクスペリエンスのためにリダイレクトせずに同じURLを維持する必要があります。

@Janpot https://github.com/nuxt-community/nuxt-i18n/issues/422

Nuxtjsにはいくつかのオプションがあります（未定義、true、false）

Nextjsにもサーバーオプションを選択する必要がありますか？

リダイレクトの理由は、検索エンジンに重複するコンテンツが表示されないようにするためです。 あなたの正確なユースケースは何ですか？

@Janpot私たちのAPIには、多くの場所で末尾にスラッシュがあります。 最新のリリースでは、末尾にスラッシュが付いたURL（/ api / test /-> / api / test）が一致しないため、バックエンドで多くの404が発生します。

それがすべての人に役立つかどうかはわかりませんが、私はこの解決策が私に役立つことを発見しました。 _app.jsファイルに入れます。

static async getInitialProps(ctx) {
    const appProps = await App.getInitialProps(ctx);

    // Remove trailing slash
    const path = ctx.router.asPath,
            res = ctx.ctx.res;

    if (path.length > 1 && /\/$/.test(path)) {
        res.writeHead(301, {Location: path.slice(0, -1)})
        res.end();
    }

    return {...appProps};
}

@mlbonniec Next.jsアプリで深刻なパフォーマンスの低下を引き起こすため、コメントを最小限に抑えました。

最新のnext@canaryバージョンはこのバグを修正しています。代わりにアップグレードしてください！

@mlbonniec Next.jsアプリで深刻なパフォーマンスの低下を引き起こすため、コメントを最小限に抑えました。

最新のnext@canaryバージョンはこのバグを修正しています。代わりにアップグレードしてください！

問題ない！
しかし、私は以前に更新しました、そしてそれは問題を解決しませんでした。
npm update

最新のNext.jsカナリアでバグが修正されない場合は、新しい問題を開いて確認してください。 🙏

簡単な質問ですが、 next exportプロジェクトはこの変更をどのように処理しますか？ 末尾のスラッシュのページごとにまったく新しいページを作成することによって？ エクスポートされたアプリがHTTPリダイレクト（または書き換え）を指定できるとは思いません。

next exportを使用するプロジェクトでは、クライアント側のすべての<Link />が正しく更新されますが、サーバー側のリダイレクトでは手動で構成する必要があります。 サーバーレスターゲットまたはnext startデプロイされたプロジェクトは、これらの設定を自動的に構成します。

@Timerこれが完全なリリースに達した後でも、実験的なオプションを使用する必要がありますか？

@Timerこれが完全なリリースに達した後でも、実験的なオプションを使用する必要がありますか？

いいえ、そのまま利用できます。

trailingSlashオプションはnext exportないと思いますか？ たとえば、githubページで/page/を/page （またはその逆に）リダイレクトする最良の方法は何ですか？

trailingSlashオプションはnext exportないと思いますか？ たとえば、githubページで/page/を/page （またはその逆に）リダイレクトする最良の方法は何ですか？

私の知る限り、githubページにはリダイレクト機能がありません。 これはvercel.comで箱から出してすぐに機能しますが、趣味のプロジェクトでも無料です（githubページのように）。

next exportを使用するプロジェクトでは、クライアント側のすべての<Link />が正しく更新されますが、サーバー側のリダイレクトでは手動で構成する必要があります。 サーバーレスターゲットまたはnext startデプロイされたプロジェクトは、これらの設定を自動的に構成します。

こんにちは@Timer詳しく説明していただけますか？ 手動で構成するにはどうすればよいですか？ これが私の状況です。 私のウェブサイトでは、 next-i18nextを使用しています。 next build && next exportでデプロイした後、すべての内部リンクは機能しますが、手動でURLを入力すると、どれも機能せず、404エラーが発生します。 ここからtrailingSlash:trueを使用することにしたので、手動で/pricingと入力すると機能しますが、 /zh/pricing 404エラーが発生します。