Leaflet地图报错：_latLngToNewLayerPoint为null的根因与修复-代码聚汇网

Leaflet地图报错：_latLngToNewLayerPoint为null的根因与修复

英语主播皮卡丘·2026-08-29·阅读 22 GEO检测（免费）

LeafletTypeError_latLngToNewLayerPoint

|难度：普通|阅读约 46 分钟

下午三点，测试同学甩过来一张截图：控制台一整片红色，第一行写着 Marker.js:330 Uncaught TypeError: Cannot read properties of null (reading '_latLngToNewLayerPoint')。页面上的地图白屏，只有左上角缩放按钮还孤零零地挂着。说实话，这个报错里的 _latLngToNewLayerPoint 属于 Leaflet 的内部方法，名字又长又拗口，第一次遇到的人很容易懵。但你只要理解了它背后的运行机制，就会发现这个错误其实是一类非常典型的问题——地图实例还在，marker 却找不到自己的"宿主"了。

这篇文章会把这个报错从报错信息、源码位置、根因链路到实际项目里的几种触发姿势完整拆一遍，再给出修复方案和防御措施。无论你是原生 JavaScript 调 Leaflet，还是 Vue、React 里封装地图组件，只要你跟 L.marker() 打过交道，这篇都值得存一下。

1. 报错信息解剖：Marker.js:330 的每一部分在说什么

1.1 报错的字面含义

先看这一整句话在 JavaScript 引擎层面到底发生了什么。

Cannot read properties of null (reading '_latLngToNewLayerPoint') 翻译成人话就是：代码尝试在一个值为 null 的对象上读取 _latLngToNewLayerPoint 属性，读取失败，所以抛出了 TypeError。

这里的关键不是 _latLngToNewLayerPoint 本身多神秘，而是它的调用方 this._map 是 null。在 JavaScript 里，除了 null 和 undefined，其他值上读属性一般不会直接崩——比如在数字或字符串上读属性顶多得到 undefined。唯独在 null 上读属性，引擎会立刻抛错。

Uncaught 表示这个错误没有被任何 try/catch 捕获，一路冒泡到了全局。这意味着它会导致当前执行栈中断，如果后续逻辑依赖这次调用（比如 marker 的坐标更新、图层重绘），那页面就会表现出"地图白屏""缩放按钮失灵"这一类问题。

1.2 为什么报错定位在 Marker.js 而不是你的业务代码

Marker.js:330 的意思是报错发生在 Leaflet 源码的 Marker.js 文件第 330 行。自己写的代码没有出现在报错栈的最顶层，说明这个错误是在 Leaflet 内部的方法执行过程中抛出来的。

这其实是很多新手容易误解的地方：报错定位在框架源码里，不代表你的代码就没问题，恰恰相反，往往是你传进去的参数或调用时机不对，才把框架内部代码推到了非法状态。

以 Leaflet 1.9.x 的源码为例，Marker.js 中有一个 _animateZoom 方法：

javascript复制// Leaflet 1.9.x 源码片段
_animateZoom(e) {
    const pos = this._map._latLngToNewLayerPoint(this._latlng, e.zoom, e.center);
    this._setPos(pos);
}

当地图触发缩放动画时，Leaflet 会让每个 marker 调用这个方法重新计算自己在屏幕上的像素位置。计算需要的核心数据来自 this._map。如果某个 marker 的 _map 是 null——也就是它没有被挂在任何地图实例上——这一步就会抛错。而方法定义在 Marker.js 里，所以错误栈把位置指向了 Marker.js 第 330 行。

换句话说：报错位置是果，marker 的 _map 为 null 才是因。

1.3 谁在调用 `_latLngToNewLayerPoint`

这个方法是 Map 实例内部用于坐标转换的核心方法。_latLngToNewLayerPoint 做的事情是：把一个经纬度坐标（LatLng）和当前地图缩放级别、中心点结合，换算成该 marker 在屏幕图层中的像素点坐标。

你可能会问：Leaflet 不是有公开方法 latLngToLayerPoint 吗？为什么内部用带下划线的 _latLngToNewLayerPoint？因为这是内部 API，它多接收两个参数：zoom 和 center，允许在缩放动画过程中用动画中间态的缩放级别和中心点来计算位置，而不是用地图当前最终状态。这样 marker 才能在缩放过程中平滑移动。

_latLngToNewLayerPoint 前面有下划线，说明它不属于 Leaflet 的公开 API 承诺范围，内部版本更新时可能说改就改。我们不需要关心它的具体算法，但必须知道：它只能在地图实例上调用，而且调用它的时候，必须有合法的 zoom 和 center 状态。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 根因定位：一个 marker 在 Leaflet 内部的完整生命周期

2.1 从 `L.marker()` 到 `addTo()`：map 引用是如何建立的

要理解 _map 为什么为 null，得先看一个 marker 从创建到挂载到地图的完整过程。

假设你写了两行代码：

javascript复制const marker = L.marker([39.9042, 116.4074]);
marker.addTo(map);

第一行 L.marker([lat, lng]) 只是创建了一个 marker 对象。此时这个 marker 的 _map 属性是 null。它知道自己的经纬度坐标，但没有跟任何地图产生关联。

第二行 marker.addTo(map) 内部会调用 marker 的 onAdd(map) 方法，Leaflet 会把 map 实例挂到 marker 的 _map 属性上，同时把 marker 的图标 DOM 元素插入到地图的 overlay pane 中。onAdd 里面大致是这样一段逻辑：

javascript复制// 简化后的 Leaflet Marker onAdd 逻辑
onAdd(map) {
    this._map = map;                 // 建立 map 引用
    this._initIcon();                // 创建图标 DOM
    this.update();                   // 计算位置并渲染
    map.on('moveend', this._updatePosition, this);  // 监听地图移动
}

只要 addTo 没有被调用，或者 addTo 被调用时传入的不是一个有效地图实例，marker 的 _map 就会一直是 null。

反过来也有一种情况：marker 曾经成功 addTo 过，_map 有值；但之后地图实例被销毁了（map.remove()），而 marker 对象还被外部引用着。此时 map 内部已经清理了所有事件监听和引用，但 marker 自己持有的 _map 引用不会自动被清空。如果这个"幽灵 marker"还在某个地图事件回调里被访问，一样会出问题——不过这种情况报错往往会变成读取 _container 之类的属性，等下在后面通病部分详细说。

2.2 缩放动画和事件回调是"定时炸弹"

刚才说的都是"同步流程"里的问题，但实际报错往往发生在异步流程里。

回想一下 _animateZoom 的执行时机：当地图进入缩放动画时，Leaflet 会触发 zoomanim 事件。marker 如果启用了缩放动画（这是默认行为），就会在 zoomanim 事件回调里调用 _animateZoom。这个回调的执行时间点完全由地图的动画循环驱动，而不是由你的业务代码直接控制。

这就产生了一个可怕的时间窗：你在地图缩放动画进行到一半的时候，移除了一个 marker 或销毁了地图，但动画帧队列里还留着对这个 marker 的方法调用。动画帧继续执行时，发现 marker 的引用还在，但 marker._map 已经不是有效地图实例了。于是 _latLngToNewLayerPoint 被一个不再与地图关联的 marker 调用，爆炸。很多"偶尔出现""切换页面才出现"的怪问题，本质都是这个异步时间窗导致的。

2.3 该方法的执行链：onAdd 到 update 再到像素坐标

完整执行链通常是这样的：

调用 marker.addTo(map)。
Leaflet 执行 onAdd(map)。
onAdd 里调用 this.update()。
update() 内部调用 this._map.latLngToLayerPoint(this._latlng)（公开方法）或类似内部方法。
得到像素坐标后，调用 _setPos(pos) 设置图标 DOM 的 CSS transform。

而 _animateZoom 这条链是：

地图缩放级别变化，触发 zoomanim 事件。
marker 的事件回调执行 _animateZoom。
_animateZoom 调用 this._map._latLngToNewLayerPoint(...)。
如果 this._map 为 null，抛错。

这两条链的唯一共同点：每一步都依赖 this._map 有值。 只要 _map 有值且指向一个尚未销毁的地图，marker 就能正常完成坐标换算和渲染。否则，任何调用时机都会成为新的崩溃点。

3. 触发场景重现：四种常见写法为什么都会踩坑

光知道原理还不够，我在实际项目里见过太多这个报错的具体触发姿势了。下面四种场景基本覆盖了绝大多数情况，每一种都有对应的真实项目痕迹。

3.1 Vue 场景：地图实例在 data 中声明导致的时序错乱

在 Vue 2 里最常见的写法是这样：

javascript复制export default {
  data() {
    return {
      map: null,
    };
  },
  mounted() {
    this.map = L.map('mapContainer').setView([39.9042, 116.4074], 13);
    // 拿到地图实例后创建 marker
    this.initMarkers();
  },
  methods: {
    initMarkers() {
      const marker = L.marker([39.9042, 116.4074]);
      // 注意：这里没有 addTo，或者 addTo 时 map 还没赋值
      this.map.addLayer(marker);
    },
  },
};

表面看没问题：mounted 里先创建地图，再初始化 marker。但如果 initMarkers 被某个异步回调触发，或者业务上有一句提前执行了，this.map 就是 null。null.addLayer(marker) 会先在 Map.js 内部炸开，报的是另一个错。而如果这个调用晚于地图销毁时机，marker 已经存在但 _map 被清理了，就会在动画回调里炸出 _latLngToNewLayerPoint 的错。

更隐蔽的是 Vue 2 的 data 响应式代理。把 Leaflet 的 map 实例放进 data 里，Vue 会尝试给 map 实例的每条属性都加上 getter/setter。Leaflet 内部在图层管理、事件派发时对大量属性进行了赋值和读取，这些操作被 Vue 的响应式系统拦截后，性能会下降，而且某些内部属性被代理后可能产生意料之外的时序问题。我遇到过不止一次：map 放在 data 里导致 marker 的 _map 引用在赋值后被 Vue 代理对象包了一层，结果事件回调里访问到的是代理过的 map，方法调用链条整个错乱。

正确做法是：地图实例放在 data 之外，用一个普通属性保存。 比如在 created 里挂 this.mapInstance = null，或者直接用 this.mapObj 这种非响应式属性。

3.2 React 场景：effect 依赖数组漏掉关键依赖

React 函数组件里常见的写法是：

jsx复制useEffect(() => {
  const map = L.map('mapContainer').setView([39.9042, 116.4074], 13);
  const marker = L.marker([39.9042, 116.4074]).addTo(map);
  return () => {
    map.remove();
  };
}, []);

这段代码在组件挂载后创建地图和 marker，卸载时销毁地图，看起来没问题。但问题往往出在第二种 effect 里：

jsx复制useEffect(() => {
  if (!map) return;
  const marker = L.marker([39.9042, 116.4074]).addTo(map);
  return () => {
    // 只移除了一个 marker，没有做其他清理
    map.removeLayer(marker);
  };
}, [map]);

这里的 map 来自 useRef 或者从上一个 effect 的 setState 里拿到的。如果 map 在 effect 执行时还是 null，代码提前 return 了，倒还好。真正危险的是：第一个 effect 清理函数执行了 map.remove()，把地图销毁了，但第二个 effect 的清理函数里 map.removeLayer(marker) 只是从图层层级移除 marker，不会把 marker 内部对旧地图的事件监听和引用完全清理干净。组件下一次渲染时，如果某个动画帧里触发了 marker 的 _animateZoom，而 marker 的 _map 指向的已经是一个被 remove 过的地图实例，就会抛错。

一个我亲自踩过的坑：React 18 StrictMode 下，useEffect 在开发环境会执行两次挂载→卸载→挂载。第一个地图实例被 map.remove() 销毁后，如果 marker 数组是模块级变量或者没有随组件一起重建，第二次挂载时新的 marker 可能访问到旧的、已经失效的 _map 引用。

3.3 原生 JS 场景：tab 切换后地图容器被销毁

这个场景在后台管理系统里最常见。页面有多个 tab，每个 tab 里有独立地图。用户切走时，代码把地图容器 DOM 隐藏甚至删除了，但 map 实例还保留在全局变量里：

javascript复制let map = null;

function switchTab(tabId) {
  if (tabId === 'mapTab') {
    if (!map) {
      map = L.map('mapContainer').setView([39.9042, 116.4074], 13);
    }
  } else {
    // 只是隐藏，没有销毁地图
    document.getElementById('mapContainer').style.display = 'none';
  }
}

问题在哪里？容器被 display: none 后，Leaflet 计算地图尺寸时拿到的是 0 宽 0 高。当 tab 切回来时，Leaflet 会触发一个 invalidateSize 流程来重新计算尺寸。这个流程里 marker 的坐标更新会被触发，如果 marker 的 _map 引用因为某些原因失效（比如容器被整个移除再重新插入，导致 map 内部的 pane DOM 节点丢失），就会在动画或更新过程中炸出类似的 TypeError。

更极端的情况是 tab 切换时直接执行了 map.remove() 但没有把 map 变量置为 null。下次切回来时，if (!map) 判断不成立，代码直接拿着一个已经销毁的 map 实例去创建 marker：

javascript复制if (!map) {
  map = L.map('mapContainer').setView([39.9042, 116.4074], 13);
}
// 假设这里 map 已经被 remove 过了，但不为 null
L.marker([39.9042, 116.4074]).addTo(map);

此时 marker 的 addTo(map) 会尝试访问 map 内部已经被置空的 _container 或 _layers，加上后续缩放动画事件，就出现了 _latLngToNewLayerPoint 读 null 的经典报错。

3.4 异步数据场景：接口返回后才创建 marker 的竞态问题

这个场景本质是前一个场景的变体，但值得单独拿出来说，因为它和"缓存、竞态、异步时序"绑定得特别深。

典型代码：

javascript复制let map = L.map('mapContainer').setView([39.9042, 116.4074], 13);

fetch('/api/markers')
  .then(res => res.json())
  .then(data => {
    // 用户可能在接口返回前已经切走了页面，而 map 已被销毁
    data.forEach(item => {
      L.marker([item.lat, item.lon]).addTo(map);
    });
  });

接口返回前，组件被销毁，map.remove() 被执行，map 变量被置为 null。接口返回后，then 回调里执行 addTo(map)，此时 map 是 null，一看就是个定时炸弹。但实际报错不一定在你写的这行代码处，因为 addTo(null) 可能会在 Leaflet 内部先报别的错。真正和 _latLngToNewLayerPoint 挂钩的，是你在这个异步回调里先创建了一个 marker 但没有立刻 addTo，而是在后续某个地图缩放事件里才 addTo，中间地图被销毁了。

不管细节怎么变，根因都一样：异步回调执行时机晚于地图实例有效生命周期。 这类问题还时常伴随内存泄漏，因为接口返回的 marker 数据永远没机会被挂载，却还持有闭包引用。

4. 修复与防御：让 marker 永远不在 null 上读属性

4.1 最直接的修复：addTo 之前显式判空

先给个最实用、最不容易出错的兜底方案。在创建 marker 后、addTo 前，加一层空值判断：

javascript复制function addMarkerToMap(map, latlng, options) {
  if (!map) {
    console.warn('地图实例不存在，已跳过 marker 创建');
    return null;
  }
  const marker = L.marker(latlng, options);
  marker.addTo(map);
  return marker;
}

这样做的好处是：即使业务代码因为时序问题在 map 为 null 时调用了这个函数，也不会抛错，而是打一条提示日志，告诉你"现在还不是创建 marker 的时候"。排查问题的时候看到这条 warn 就明白什么时序需要调整了。

但要注意，判空只是"止血"，不是"治病"。如果你只是判空然后什么都不做，marker 数据就丢了。 在正式项目里，更好的方案是把这些没来得及添加的 marker 缓存起来，等地图实例准备好之后再补上。

4.2 框架层面的正确姿势：Vue/React 中的生命周期管理

既然问题的根源是地图和 marker 的生命周期不同步，那框架层面就要让它们的生命周期保持严格同步。

Vue 2/3 的推荐做法：

javascript复制export default {
  // 不放到 data 里，避免响应式代理
  data() {
    return {
      markerLayer: null,
    };
  },
  mounted() {
    this.initMap();
  },
  beforeUnmount() {
    this.destroyMap();
  },
  methods: {
    initMap() {
      this.mapInstance = L.map('mapContainer').setView([39.9042, 116.4074], 13);
      this.markerLayer = L.layerGroup().addTo(this.mapInstance);
    },
    addMarker(latlng) {
      if (!this.mapInstance || !this.markerLayer) return;
      const marker = L.marker(latlng);
      marker.addTo(this.markerLayer);
      return marker;
    },
    destroyMap() {
      if (this.mapInstance) {
        this.mapInstance.remove();
        this.mapInstance = null;
        this.markerLayer = null;
      }
    },
  },
};

几个关键点：

mapInstance 不放在 data 里，避免 Vue 响应式代理干扰 Leaflet 内部属性赋值。
用一个 markerLayer 统一管理所有业务 marker。销毁地图前，Leaflet 的 map.remove() 本身会移除所有图层和 marker，但如果你用 layerGroup 管理，还可以在销毁地图前显式清空 markerLayer，双保险。
destroyMap 里把 mapInstance 和 markerLayer 都置为 null，确保后续任何异步回调进来时判空能拦住。

React 函数组件的推荐做法：

jsx复制useEffect(() => {
  const map = L.map('mapContainer').setView([39.9042, 116.4074], 13);
  mapRef.current = map;
  const markerLayer = L.layerGroup().addTo(map);

  return () => {
    markerLayer.clearLayers();
    map.remove();
    mapRef.current = null;
  };
}, []);

所有新增 marker 统一走 markerLayer 添加，而不直接 addTo(map)：

jsx复制const addMarker = useCallback((latlng) => {
  const map = mapRef.current;
  if (!map) return;
  const marker = L.marker(latlng);
  marker.addTo(layerRef.current);
}, []);

这个模式在 React 组件卸载时，先清空 markerLayer，再销毁 map，最后把 ref 置空。任何一个后续的异步回调进来，if (!map) 都能拦住。

4.3 终极防御：封装一个自定义 Marker 管理器

如果你的项目里地图和 marker 的使用频率非常高，多处创建、多处销毁，我建议花一两个小时封装一个轻量的 MarkerManager。它不需要多复杂，核心就是两张表加三个方法：

javascript复制class MarkerManager {
  constructor() {
    this._map = null;
    this._markers = new Map();   // id -> marker
    this._pendingMarkers = [];   // map 未就绪时暂存的 marker 数据
  }

  bindMap(map) {
    this._map = map;
    this._flushPending();
  }

  unbindMap() {
    this._clearAllMarkers();
    this._map = null;
  }

  addMarker(id, latlng, options = {}) {
    if (!this._map) {
      this._pendingMarkers.push({ id, latlng, options });
      return null;
    }
    if (this._markers.has(id)) {
      this.removeMarker(id);
    }
    const marker = L.marker(latlng, options).addTo(this._map);
    this._markers.set(id, marker);
    return marker;
  }

  removeMarker(id) {
    const marker = this._markers.get(id);
    if (marker && this._map) {
      this._map.removeLayer(marker);
    }
    this._markers.delete(id);
  }

  getMarker(id) {
    return this._markers.get(id) || null;
  }

  _clearAllMarkers() {
    this._markers.forEach((marker) => {
      if (this._map) {
        this._map.removeLayer(marker);
      }
    });
    this._markers.clear();
  }

  _flushPending() {
    if (!this._map) return;
    for (const item of this._pendingMarkers) {
      this.addMarker(item.id, item.latlng, item.options);
    }
    this._pendingMarkers = [];
  }
}

使用方式：

javascript复制const markerManager = new MarkerManager();

// 地图初始化完成后绑定
markerManager.bindMap(map);

// 任何时候都能安全调用，哪怕地图还没就绪
markerManager.addMarker('point-1', [39.9042, 116.4074]);

// 组件销毁时解绑
markerManager.unbindMap();

这个管理器解决了三件事：

统一管理所有 marker 的生命周期，不会出现某个 marker 游离在地图之外。
pending 机制天然抵消了异步时序问题：即使接口返回时地图还没就绪，marker 数据也会被缓存，等地图就绪后自动补上。
告别手动逐个 removeLayer：unbindMap 一次性清理所有 marker，避免内存泄漏和幽灵事件回调。

4.4 针对缩放动画的特殊防御：关闭动画

如果排查了半天，发现你确实存在"地图已销毁，但缩放动画还在执行"的情况，还有一个简单粗暴但有效的办法——显式关闭 marker 的缩放动画：

javascript复制L.marker(latlng, {
  // 关闭 marker 的缩放动画
  // 这样地图缩放时 marker 不会走 _animateZoom 分支
}).addTo(map);

看 Leaflet 源码里 marker 的 option 定义：

javascript复制options: {
    icon: new IconDefault(),
    interactive: true,
    keyboard: true,
    title: '',
    alt: '',
    opacity: 1,
    riseOnHover: false,
    riseOffset: 250,
    pane: 'markerPane',
    shadowPane: 'shadowPane',
    bubblingMouseEvents: false,
    autoPanOnFocus: true,
    dragging: true,
    // 这个选项决定 marker 是否参与缩放动画
    markerZoomAnimation: true,   // 默认开启
}

创建 marker 时把 markerZoomAnimation 设为 false，那么地图缩放时 marker 会走普通的 moveend 更新逻辑，而不会进入 _animateZoom 分支。如果你遇到的报错恰好是缩放动画瞬间触发的，这个设置能直接绕开。代价是：地图缩放过程中，marker 的位置更新看起来会有极轻微的延迟感，因为它是 moveend 时才重算的，不过对于绝大多数业务场景来说肉眼几乎察觉不到差别。

5. 从这一个报错看前端地图开发的通病

5.1 类似的 null 报错家族：不只是 `_latLngToNewLayerPoint`

_latLngToNewLayerPoint 只是 Leaflet 内部方法里报出标题名的一个。整个 Leaflet 源码中，和它类似的 null 读取错误多得很。你在排查地图相关问题时通常会遇到这些：

报错信息片段	通常含义
`Cannot read properties of null (reading '_latLngToNewLayerPoint')`	marker 的 `_map` 为 null，缩放动画中坐标计算失败
`Cannot read properties of null (reading '_map')`	访问了 map 内部某个对象的 `_map` 引用，但对象已脱离地图
`Cannot read properties of null (reading '_container')`	地图实例还在，但容器 DOM 已被移除或从未正确创建
`Cannot read properties of null (reading '_layers')`	地图内部图层管理对象被销毁后仍被访问
`Cannot read properties of undefined (reading '_latLng')`	marker 的 `_latlng` 未初始化，通常是因为非法坐标

这些报错本质都属于同一类：在地图（或图层）实例的生命周期之外访问了它的内部属性。 排查思路也是完全一致的：先确认报错的宿主对象是哪个，再确认对象的生命周期是否跨越了某个业务边界（页面切换、tab 切换、接口返回、组件销毁）。

5.2 把地图实例当作资源来管理，而不是当作普通对象

我在多个项目里和不同同事排查地图问题时，发现最容易出问题的人通常有一个共同心态：把 Leaflet 的 map 实例当成一个普通的、随时可用的对象，只关注"创建"和"销毁"两个动作，忽略了它背后还有一堆异步事件、DOM 生命周期和图层状态。

实际上，Leaflet 的 map 实例更接近一个"有状态资源"。它的状态机是这样的：

初始化前：map 实例不存在，任何 marker 操作都不能执行。
初始化中：容器 DOM 必须存在，地图尺寸计算依赖可见的容器。
运行中：可以自由添加和移除 marker、图层、事件监听。
销毁中：需要先移除所有事件监听和图层，再清空容器 DOM。
销毁后：实例完全不可用，任何操作都可能产生不可预期的副作用。

正确的资源管理姿势是：

创建地图时，明确记录资源状态（比如用一个 isMapReady 布尔值）。
所有 marker 统一走一个管理器，不要散落在各处单独 addTo。
销毁时，按照"先清业务图层，再销毁地图，最后置空引用"的顺序操作。
异步回调里访问地图前，一律判空。

5.3 排查这个报错的完整步骤清单

最后递一份排查清单，下次遇到类似报错直接照着走：

第一步：确认报错出现的时间点。是页面首次加载就出现，还是切换 tab、关闭弹窗、路由跳转之后出现？这决定了是初始化时序问题还是销毁时序问题。

第二步：在报错的业务代码处打断点，查看抛出报错的 marker 对象。在控制台里输入：

javascript复制marker._map

如果输出是 null，说明 marker 没有完成 addTo，或者 addTo 之后地图被移除，引用失效。

第三步：在创建 marker 的代码处加日志，确认 addTo(map) 执行时 map 是否为有效实例。

第四步：检查地图容器 DOM。执行：

javascript复制document.getElementById('mapContainer')

确认容器是否存在，以及它的 offsetWidth 和 offsetHeight 是否大于 0。如果容器是隐藏的或尺寸为 0，地图内部很可能已经进入了异常状态。

第五步：如果在 Vue/React 中使用，检查地图实例是否被放进了响应式系统或 state 管理里。如果是，立刻把它移到非响应式属性或 ref 里。

第六步：如果要彻底解决，推荐实现一个 MarkerManager 或者统一图层管理，杜绝散养式 marker。

5.4 我在实际项目里的几点体会

每次排查到"地图已销毁，但某个异步回调还在操作 marker"这种问题时，我都会反问一句：为什么会等到销毁之后还有回调在跑？答案往往是某个定时器、网络请求或全局事件监听没有在组件销毁时一并清理。所以解决 _latLngToNewLayerPoint 报错的过程，其实也是在逼着你审视整个异步链路是否健壮。

另外说一个小技巧：如果你用的是 Leaflet 1.9.x，可以临时在浏览器控制台里执行 window.L = L，然后在报错处右键"Break on caught exceptions"（在某些调试器里是 Break on exceptions），可以直接停在抛错的源码行。配合 Call Stack 面板查看调用方，通常几秒就能定位到是谁触发了这次非法调用。

还有一点容易被忽略：Leaflet 的版本不同，源码行号差异很大。1.7、1.8、1.9 以及 2.0 测试版的 Marker.js 内部实现都不一样。你上网搜索时如果看到别人贴的行号和你本地报的不一样，先确认 Leaflet 版本，再对照源码。不要被网上的"标准答案"带偏，多看看自己项目里实际跑的版本源码最靠谱。