プロパティまたはメソッド「__v_isRef」はインスタンスで定義されていませんが、レンダリング中に参照されます。プロパティを初期化することにより、データ オプションまたはクラスベースのコンポーネントのいずれかで、このプロパティがリアクティブであることを確認してください。
マイクロ フロントエンド アーキテクチャでは、メイン アプリケーションは vuex ストアを介してサブ アプリケーションにパラメーターを渡し、データとメソッドを取得します。しかし、特定のサブアプリケーションで、どこに何が書かれているかわかりません。メインアプリケーションのストアを使用した後、メインアプリケーションのすべての Vue コンポーネントが上記のエラーを報告します。
他のサブアプリケーションはこの方法で作成できますが、このサブアプリケーションには問題があります。
除外方法により、ストアの属性を 1 つずつ除外すると、_vm 属性がある限りエラーが報告され、他の属性は直接報告されないことがわかりました。
ストア内の _vm は、下の図に示すように、メイン アプリケーションの vue インスタンスです。
ソース コードを表示すると __v_isRef が表示されます。これは、Object.defineProperty を使用して、列挙不可および書き込み不可のプロパティを定義しています」 __v_isRef" ラッパー オブジェクト wrapper の場合、その値は true になり、現在のオブジェクトが通常のオブジェクトではなく ref であることを区別するために使用されます。
したがって、それ自体はレスポンシブ プロパティとして vue インスタンスの下にマウントされません。
ただインスタンス配下のレスポンシブ属性に__v_isRefが使われている理由はわかりませんが、メインアプリのvueインスタンスがストアの_vmを介してサブアプリに渡され、その後何らかの操作が行われていることが大まかな理由と推測されますサブアプリの(何の操作かわからない)直接データ宣言での_vmの再帰レスポンシブ処理がメインアプリのvueインスタンスで問題を起こしていました。
最後に、長い間調べたところ、node_modules の依存関係の問題であることがわかりました。これは、サブアプリケーションのビルド時に依存関係をロックするロック ファイルがなく、一部の依存関係が自動的にアップグレードされたためです。他のサブアプリケーションに従って依存関係をロックし (ほとんどのサブアプリケーションの依存関係は同じです)、変更されたアプリケーションの通常の依存関係を再度ロックし、ロック ファイルを送信して通常の状態に再構築しました。
ただ、サードパーティに依存する node_modules のデメリットでもある依存関係が存在するため、どの依存関係が原因なのかはまだ不明です。