TypeScript能否用其他字段值初始化字段？ESLint报错是否合理？

1. 方法1完全不是错误实践 #

首先可以明确：方法1是完全合规的合法写法，既符合TypeScript官方语法规范，也匹配ES2022之后的ECMAScript标准类字段逻辑。从你贴的转译结果也能看出来，类字段的初始化逻辑会被自动插入到构造函数的参数初始化之后、构造函数自定义逻辑之前运行，此时this已经完成实例化，访问this.service是100%安全的，不存在运行时问题。

2. ESLint的报错属于典型误报 #

原生ESLint的no-invalid-this规则本身是为纯JavaScript场景设计的，它没有适配TypeScript的类字段初始化场景，识别不了这个场景下this的合法指向，才会抛出错误。
实际使用中只要把ESLint配置里的原生no-invalid-this关掉，换成@typescript-eslint/eslint-plugin提供的@typescript-eslint/no-invalid-this规则，就能完全解决这个误报，不会影响方法1的正常使用。

3. 方法1没有成为首选推荐的原因很实际 #

主要有三个核心原因：

• 历史习惯问题：TypeScript在2.7版本才正式支持类字段初始化时访问this，在此之前官方文档就已经把方法2作为标准推荐写法，多年的使用习惯形成了路径依赖，很多老教程、老项目都沿用了方法2的写法。
• 显式类型更利于协作：方法2显式标注了字段的类型，其他协作的开发者看代码时不需要跳转到getSomeResultWithAComplicatedType的定义，就能直接知道field1的类型结构，大型项目里可维护性更好。
• 可以主动拦截不符合预期的类型变更：如果你业务上要求field1的类型必须固定为MyExtremelyComplicatedType，方法2会在getSomeResultWithAComplicatedType的返回值类型意外变更时，直接在Foo类这里抛出类型错误，提前发现问题。而方法1只会自动推导新的返回值类型，不会主动报错，如果类型变更不符合业务预期，反而会把问题藏得更深，等到实际使用字段时报错。

当然这不是说方法1不好，在小项目、个人开发或者你确实需要优先保证重构效率的场景下，方法1的优势非常明显，完全可以放心使用。

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