Es scheint ein Speicherleck in der Datei store.js zu geben. Wenn Benutzer durch verschiedene Themen navigieren, scheint die _identityMap bei jeder RESTful-Anfrage schnell zu wachsen. Ohne eine angemessene Bereinigungslogik wird die Map bei großen JS-Heaps den Speicher erschöpfen.
Vielleicht reicht es aus, store.js eine pruneMap-Funktion mit einem FIFO-Algorithmus hinzuzufügen, um die frühesten Maps zu entfernen?
Auch die Variable const MAX_ITEMS_PER_TYPE = 500; kann weiter diskutiert werden, um ein Gleichgewicht zwischen Cache und Speicherplatz zu finden.
Reproduktionsschritte sind wie folgt: Der Benutzer springt mehrmals hintereinander, ohne die Seite zu aktualisieren, von einem Thema zum nächsten, indem er das „Vorgeschlagen/Verwandt“ unter dem Thema verwendet, und die JS-Heap-Größe sammelt sich in meinem Test von den ursprünglichen 100 MB auf etwa 500 MB an, wenn genügend besuchte Themen vorhanden sind (insbesondere bei Themen mit vielen Beiträgen darunter). Und die Rückkehr zur Startseite gibt diesen Teil des belegten Speichers nicht frei.
Diese JS-Heap-Größe kann in der Browserkonsole unter „Leistung“ eingesehen werden, und der Speicherverbrauch kann im Prozessmanager des Browsers eingesehen werden.
Ich habe ein Video davon im PR angehängt, das nur das Problem demonstriert (etwa 3 Minuten, wenn dieselbe Seite über Stunden verwendet wird, wird sich die Situation verschlimmern).
Und das Hinzufügen eines Haltepunkts hier zeigt auch die wachsende Menge an Elementen in _identityMap:
