ESLint object-shorthand 修复后报 super keyword outside a method

原代码能解析，eslint --fix 后却报 Parsing error: 'super' keyword outside a method。若启用了 object-shorthand: ['error', 'never']，检查它是不是把使用 super 的对象方法改成了普通函数属性。

ESLint 10.10.0 的明确输入与错误输出是：

// 原输入
const obj = { describe() { return super.toString(); } };

// 不安全的自动改写
const broken = { describe: function () { return super.toString(); } };

对象方法中的 super 有方法语义所需的上下文。把函数体原样搬进普通 function，并不能保留这项语法条件；这不是 parser 太旧，也不是缺少 TypeScript 配置。

先恢复自动修复造成的无效改动

保存修复前后的 diff，只恢复这次把方法改成函数的错误编辑，保留其他已经确认的修改。若编辑器保存会再次触发 fix，先暂停该文件的这条自动写入，再修正文稿。

不要把 super.toString() 机械改成 this.toString()。super 与 this 的属性查找起点不同，后者还可能调用对象自己的同名方法而进入递归。改语法与改业务行为必须分开审查。

为真正需要 super 的方法保留语法

仍需使用 never 规则时，可以在这一处保留有理由的局部豁免：

const obj = {
  // eslint-disable-next-line object-shorthand -- super requires method syntax
  describe() { return super.toString(); },
};

这段注释只豁免下一行的指定规则，不应扩成关闭整份 lint。项目若禁止内联配置，需要在既有配置流程里对相应文件安排例外，不能以无效注释假装已经关闭修复。

也可以重新评估 never 是否符合项目代码风格，但调整全局风格规则会影响更多方法，范围比这处故障大。相关异步方法、生成器及嵌套箭头对 super 的使用，应按真实语法分别检查。

正式版本仍要检查具体修复器

已核对的 ESLint 10.13.0 正式 object-shorthand 代码仍会在 never 路径调用长形式转换，没有以方法体使用 super 为条件跳过。因此不能仅因问题已关闭就断言这版能安全修复这段输入。

后续采用正式修正时，先在受控副本观察自动修复输出，确认保留合法方法、解析通过，再运行项目原 lint 和相关行为检查。可用原有 --fix-dry-run 流程审查拟写入结果；成功返回文本不等于文本一定合法。

验收同时覆盖带 super 的方法与普通不带 super 的方法：前者不能被改坏，后者仍按原规则处理。已经提交或部署的错误代码需要修正相应 diff，回退 ESLint 版本不会自动撤销它。保留依赖锁文件和局部豁免，移除豁免前仍以原输入做回归。