goland 不支持对 go 文件内嵌的 javascript 代码进行 eslint 校验，因其仅识别 .js/.ts 等独立前端文件，而 go 文件中的 js 字符串被视为纯文本，不解析为 javascript ast，eslint 无法介入。

GoLand 本身不支持对 Go 文件中内嵌的 JavaScript 代码（比如 //go:embed 引入的 JS 字符串、或模板中混写的 JS 片段）进行 ESLint 校验——它只会在独立的 .js、.ts、.jsx、.tsx 文件中触发 ESLint。

为什么 Go 文件里的 JS 不会被 ESLint 扫描

ESLint 是基于文件后缀和语言类型识别目标代码的。GoLand 将 .go 文件完全交由 Go 语言服务处理，其中的字符串字面量（哪怕内容是 JS）被视为纯文本或 Go 字符串值，不会被解析为 JavaScript AST。ESLint 没有机会介入，也不会读取这些字符串内容。

• GoLand 的 ESLint 集成只监听 .js/.ts 等明确的前端文件类型
• //go:embed 加载的是编译期资源，运行时才注入，IDE 无法在编辑时“展开”字符串做语法分析
• 模板中（如 html/template）混写的 JS 属于“HTML 内联脚本”，GoLand 默认按 HTML 模式处理，不是 JS 模式

可行的绕过方案：把 JS 提取为独立文件

这是唯一稳定、可配置、能被 GoLand + ESLint 正常识别的方式。核心思路是：不让 JS “藏在 Go 里”，而是让它回归标准路径。

• 将所有内嵌 JS 逻辑移到 assets/js/ 或 web/static/js/ 下的独立 .js 文件中
• 用 //go:embed 改为加载整个目录：//go:embed assets/js/*.js
• 在 Go 中通过 fs.ReadFile 或 embed.FS 读取，再注入到 HTML 或返回给前端
• 这样 assets/js/ 下的文件会被 GoLand 当作 JS 文件打开，ESLint 自动生效

如果必须保留内嵌写法，只能靠人工+约定

没有自动校验，但可以降低出错概率：

baidu-map-jsapi-three

使用 MapV-Three 构建专业的 3D 地图和 GIS 应用 - 基于 Z-up 坐标系的 3D 地图库，支持地图编辑、测量工具、要素绘制、数据管理等地理可视化功能。适用于创建地图编辑器、测量工具、空间数据可视化等 Web-GIS 应用。

下载

• 在 JS 字符串前加 JSDoc 注释提示语言类型：/* eslint-env browser */ const x = 1;（仅起文档作用，不触发检查）
• 用 eslint-disable-next-line 注释包裹整段字符串（无效，但能提醒后续维护者此处有 JS）
• CI 阶段用脚本提取 Go 文件中的 JS 片段（正则匹配 `.*?` 或 "(.*?\n.*?)"），临时写入 .tmp.js 并跑 eslint .tmp.js —— 这需要额外工程投入，且易误报

别踩这个坑：试图用 overrides 强制匹配 .go 文件

有人试过在 eslint.config.js 里写：

overrides: [{
  files: ["*.go"],
  processor: "eslint-plugin-html/html"
}]

这行不通。因为：

• eslint-plugin-html 只处理 .html 或 .htm 后缀，对 .go 文件直接跳过
• GoLand 不会把 .go 文件交给 HTML 处理器，override 规则根本不会加载
• 即使命令行强行执行，也无法定位字符串内的 JS 起止位置，解析失败率极高

真正要校验 JS 质量，就得让 JS 出现在 JS 的地盘上。内嵌写法省事，但代价是放弃静态检查——这点在多人协作或长期维护项目里，很快就会变成技术债。