react-reverse-portal内存泄漏风险与key参数使用问题

1. 写法的内存泄漏风险与实例清理问题 #

• 你不额外包裹div、直接渲染InPortal列表的写法不存在额外内存泄漏风险。
• 当某次渲染的列表中没有包含某个InPortal实例时，React的协调流程会正常识别到该节点被移除，自动触发完整的组件卸载逻辑：对应组件的useEffect/useLayoutEffect清理函数会正常执行，React内部持有的组件实例、虚拟DOM关联引用都会被释放，可被垃圾回收机制正常回收，不需要你手动做额外清理。
• 唯一需要注意的特殊场景：如果你在组件作用域外（比如全局状态、模块级变量）长期持有了通过createPortal生成的portal节点引用，当你确认对应组件永远不会再被使用时，需要手动释放这部分自定义持有的引用，避免DOM节点因为被持续引用无法被回收——这属于业务代码的引用管理问题，和InPortal的列表写法、是否包裹外层容器没有关系。

2. InPortal对createPortal第三个key参数的支持 #

• 完全支持，你直接给InPortal组件传入标准的key属性即可，该属性会被透传到底层的ReactDOM.createPortal调用中，作为第三个参数生效。
• 你的判断是对的：给列表渲染的每个InPortal传入稳定、唯一的key，能够帮助React更精准地识别列表项的增删移动，减少非必要的组件重挂载，避免状态错乱，对无限滚动这类长列表场景的状态维护是有正向作用的。注意不要使用数组下标作为key，尽量用业务侧每个列表项的唯一ID作为key值，避免滚动加载新数据时下标变化导致的状态异常。

补充说明：你当前不额外包裹div容器的写法是完全合规的，react-reverse-portal本身就支持InPortal作为列表项直接渲染，不会带来额外的DOM层级冗余或功能异常。

内容的提问来源于stack exchange，提问作者HenrikBechmann