djangoのドキュメントには明確に記載されています
実行時にアプリケーションの設定を変更しないでください。
そのステートメントへのリンクは次のとおりです
私の質問は、なぜこれがそうなのかということです。実行時にアプリケーションを動的に追加し、実行時にデータベースを追加したいのですが、どちらも設定の編集が含まれます。実行時に設定が編集されない理由、例外が存在する場合、それらがどの設定であり、なぜ例外であるのかを誰かが説明できますか？目標を達成する方法にはあまり興味がありませんが、設定を変更してはいけない理由に興味があります。
実行時に変更した場合、ほとんどの設定は再読み込みされません。そのため、Djangoはあなたが行った変更を認識しません。
これは、Djangoが単なる通常のPythonコードであるという事実によるものです。コードを監視しているサーバーとは異なり、コードの一部にすぎません。
場合によっては、Djangoコードの一部が設定の変更に応答することがあります。これは、たとえば、メールが送信されるたびに「settings.DEFAULT_FROM_EMAIL」を実行するためです。
ただし、DjangoがINSTALLED_APPSの場合のように設定を処理する場合、何かを変更したことに気付かずに処理をやり直します。
どの設定が安全ですか？まあ、それは将来変更されるかもしれないので、ドキュメントは「どれも安全ではない」と言っています。Djangoは、何らかの理由で設定のコピーを保存したり、何らかの処理を行ったりする場合があります。
INSTALLED_APPSを変更すると、インポートされるモジュールが変更されるため、機能させることができませんでした。DjangoがPythonがこのレベルで機能する方法を回避する方法はありません-モジュールを「インポート解除」できる必要がありますが、これは基本的に不可能です（唯一の方法はプロセスを再起動することです）。クロスアプリリンクに関連する問題。
AFAIKには、実行時に設定を安全に変更できるドキュメントはありませんが、より明確にドキュメント化するように求めるオープンチケットがあります。
Djangoがプロジェクトの設定モジュールとのインターフェースに公開する設定オブジェクトの内部を見ると、実行時に設定を動的に変更することを妨げるものは何もないことがわかります。
ただし、フレームワークのアーキテクチャは、アプリケーションが初期化中に1回だけ構成されるという前提に基づいて、メモリ最適化のためにスレッド間で多くのグローバル状態が共有される要求/応答フローを中心に構築されていることを理解する必要があります。