素晴らしい問題は解決されましたが、それはまだ不明でした。
翌年に戻って、テスターは前年の3回の反復の関数に対して回帰テストを実施しましたが、Excelによってインポートされたすべての関数が無効であることがわかりました。もちろん、バックグラウンド開発者として、原因をトラブルシューティングするために実行ログを開くのは初めてです。しかし、奇妙なことに、バックグラウンドログにERROR情報がないということです...そのため、フロントエンドに切り替えたところ、Chromeの開発ツールで次の例外が見つかりました。
org.springframework.web.multipart.MultipartException：マルチパートサーブレットリクエストを解析できませんでした。ネストされた例外はjava.io.IOExceptionです：一時アップロードの場所[/tmp/tomcat.439562935221680911.8769/work/Tomcat/localhost/ROOT]は無効ですorg.springframework.web.multipart.support.StandardMultipartHttpServletRequest.parseRequest（StandardMultipartHttpServletRequest.java： 112）org.springframework.web.multipart.support.StandardMultipartHttpServletRequest。（StandardMultipartHttpServletRequest.java:86）
……
異常な情報から判断すると、アップロードされたファイルの一時ディレクトリが無効であることを理解することは難しくありません。Baiduは将来的に無効にする予定です。しかし、なぜ新年後に戻ってきた後にディレクトリが突然失敗したのですか？
関連情報のクエリを続けたところ、Springbootの起動時にファイルをアップロードするための一時ディレクトリが作成され、システムは10日後に自動的にディレクトリをクリアすることを知りました。
解決策：
1.サービスを再起動し、ディレクトリを再生成します。
2.ディレクトリを手動で作成します。
3.サービスを開始するメインメソッドで、次のコードを追加して、アップロードしたファイルのディレクトリを指定します。
@豆
MultipartConfigElementmultipartConfigElement（）{
MultipartConfigFactoryファクトリ= new MultipartConfigFactory（）;
factory.setLocation（ "/ data / apps / temp"）;
return factory.createMultipartConfig（）;
}
4.アプリケーション構成ファイルに次の構成を追加します。原則は3と同じです。
サーバ：
tomcat：
basedir：/ data / apps / temp
上記の方法のどれも私の問題を解決していないことを実践は証明しています...
次に、サーバーのtmpディレクトリに行ったところ、複数の一時的なTomcatファイルが作成されていることがわかりました。通常の状況では、ソリューション1が有効になっているはずです（ただし、この問題は永続的に解決することはできません）が、それでも例外を報告するのはなぜですか？痛いのは、新しく作成された一時ディレクトリのポートが8491であり、これは私が再起動したサービスのポートですが、例外の一時ディレクトリポートは8769であり、8769はzuulゲートウェイのポートです。それで、ソリューション4の構成情報をzuul構成ファイルに追加しましたが、それで問題ありませんでした...
私を困惑させるのは、それがズール問題である場合、最初にアップロードすべきではなく、問題が発生する前の年まで待たないということです。