逻辑别放 Vue component 里，丢一个闭包里，这样油猴脚本就没法从 DOM 节点长驱直入到你的 getParams 方法了。


https://imgur.com/vBjtUMd

@tmtstudio 方法别挂 vue 实例上

还有一个是使用 console.table 之类的方法打印大 object ，如果 devtools 打开了那么就会产生一个延迟，从而检测到 devTools 打开了。

破解方法是找到一个比任何代码都早的时机，把 console 上的一堆方法覆盖成空函数。Event Listener Breakpoints 下 Script > Script First Statement 勾上，断点就会打在所有脚本的第一条语句。

欧路词典带的背单词功能就够我用了，该有的功能都有，看释义用的还是导入的自己喜欢的词典，一本柯林斯双解一本新牛津，够了。

你要能接受按钮再套一层标签，可以一个 calc 都不用。

https://codepen.io/Will-Liu-/pen/ZEVzORK

明白你的意思了，flex 嵌套的情况下由于 gap 的存在导致 number 和 fn 两列的宽度比没法表示。

非要用 flex 的话可以把最左边的 gap 单独拎出来不参与横向 flex 空间分配，这样下来宽度就是 3:1 了，然后内部 keyboard-number 再把右边的 gap 剔除 flex 空间分配，三列数字仍然可以用 gap + space-between 而无需计算自己的宽度。

flex 也能用 gap 啊。

就是要获取 CSS 一个 block level container 中的每个 line box 包含的文字分别是什么。

可惜 CSS 并没有暴露 line box 的任何 API ，一个 p 标签最终会 render 出几个 line box 都不知道，更不用说直接获取文字是在哪个地方断开到下一行的。

SpiritQAQ 的方法非常巧妙，利用了 Range API ，一个个字符吃进去然后检测 range 的形状和坐标，一般情况应付没问题了。频繁用 Range 做 detection 不知道会不会有性能瓶颈。

<td>(.+?)(?=<)

用断言，否则后面的尖括号会被吃了

看到 OP 说是给第三方 JS 添加类型，那说明它在运行时是有问题的

declare const bar: Bar
let key = 'name';
bar[key] = new Date();
typeof bar.name // ??

key 如果是任意字符串，那它就有可能是 ‘name’。如果说运行时保证了 key 一定不是 name ，但 TS 不知道，你只能

interface Bar {
name: string;
[key: string]: string | Date;
}

然后在每次 bar[key] 的时候告诉 TS 这里 key 不会是 name 所以类型一定是 Date 。

@makelove 用 intersection type 虽然规避了同一个 interface 内声明的字段类型必须兼容 index signature 的 TS 报错，但其实这是一种错误用法，不报错可能就像你说的，.xxx 和 索引访问在进行类型交叉的时候互不干扰。

这个所谓的 index signature 必须兼容所有字段的设定，是为了规避在 bar['na'+'me'].getMonth() 这种场景下产生错误推断。

这两种类型交叉后，更准确地，我觉得 bar.name 应该推断为 string & Date ，但 JS 中怎么构造一个既是 string 又是 Date 的变量呢。

const bar2: Bar = { name: 'xx' as string & Date }

你看这样就不报错了，说明右边的 literal object 必须同时满足 Bar 的两个类型才能赋值。但是因为强行 as ，运行时 bar['na'+'me'].getMonth() 仍然要报错。

类型要安全那就只能加一层，把 name 摘出来：

interface Bar {
name: string;
dates: {[key: string]: Date}
}

或者像 #3 说的，name 用 symbol 。

module A {
const name = Symbol('name')

interface Bar {
[name]: string;
[key: string]: Date;
}

export const bar: Bar = {
[name]: 'test',
a: new Date,
bar: new Date
};
}

因为对象的 key 可能来自运行时，ts 无法推断。试想如果取 obj[key] 那 ts 应该推断其类型为 Date 还是 string ? 如果算做 Date 那万一 key 的值在运行时其实是 'name' 呢？

欧路词典背单词不是挺好的么？自己加两本新牛津和柯林斯双解，例句词性发音多释义不就都有了？查单词的时候加自己的生词本，点一下就好了。

遇到词的另一个释义再记录这种方法效率有点低的，需要你有大量语言输入，而且往往碰到了还是要靠词典才能发现常规释义在当前语境下解释不通，然后你才能意识到该词的另一个释义。一词多义的困扰还得是靠查词典，背单词的时候刻意去翻它的其他释义，留下印象，下次遇到了你就会灵光一闪，察觉到这个用法不是常规释义。好的词典是会根据使用频率对多释义排序的，所以我觉得背单词 app 的关键在词典。

abort signal 都是你自己传给 fetch 的，fetch 跟你说发生错误了，错误是 abortError ，你自己拿着刚刚传给 fetch 的 signal 一看不就知道 signal.reason 是什么。

php asp jsp 混 html 那是第一代 web 时期的做法，正好对应了 table 布局的年代，层层叠叠的 table 套 table ，也就是 DW 拖界面的年代。

后来服务端就搞 MVC/MVP 分离啦，前端成了后端的 view 层，各种框架就引进模板语言啦，什么 freemarker smart velocity ，这时候就没人用 DW 了。Web 也进入 2.0 时代 ，各种精细 UI 设计，拖拽生成布局根本无法胜任，只能手撸 HTML 然后整合进后端模板。这时候正是 DIV+ CSS float 的天下。


随着浏览器发展 IE6/7/8 的消亡，前端就迈进第三个阶段了。这个阶段开始，前端朝着组件化方向发展，网站不再是 web site, 而是 web app ，彻底让后端成为了 API Service 。开局一个空架子 index.html ，所有的 html 结构啊样式啊都在 js 里加载然后在浏览器中动态创建出来。当然传统的多页网站也没有完全消亡，不过后面各个前端框架也开始覆盖这种传统服务端多页网站的需求。

现在都组件化了，甚至严格意义上都不写 html ，写各框架基于 html 拓展的模板或者 JSX 这种。当然是手撕模板和 JSX 啊，不会再有大片 html 结构存在了，大了你就得拆分成可复用的组件，带着逻辑和样式一起复用。dw 拉界面那都是前端刀耕火种的年代的产物，那时候还是 table 布局的天下，10 几年前 DIV+CSS 流行起来后就很少有人用拖拽生成 html 了，更遑论今夕。

唢呐吧

可以用同名 interface 来声明实例类型。

```typescript
abstract class Callable<T extends (...args:any[]) => any> extends Function {
constructor() {
super('return arguments.callee._call(...arguments)');
}
protected abstract _call(...args: Parameters<T>): ReturnType<T>;
}

interface Callable<T extends (...args:any[]) => any> extends Function {
(...args: Parameters<T>): ReturnType<T>
}

class AjaxFactory extends Callable<(url: string, init?:RequestInit) => Promise<any>> {
protected override _call(url: string, init?:RequestInit): Promise<any> {
return fetch(url, init)
}
}

const request = new AjaxFactory();

request('/test', {method:'GET'})
```

https://www.typescriptlang.org/play?ssl=20&ssc=33&pln=1&pc=1#code/IYIwzgLgTsDGEAJYBthjAgwsZqTIFMAeAFQQIA8ICA7AEwwAoA6V4KAczAC5gaBPANoBdAJQIAvAD4EffjMrV6GAGIBXGvACWAexoIA3gFgAUAnNI9kKGvg6ojccbMXXYNQAcCDgORQCEGpQ+uwcagC2tBBgzLA4hATMAPpxuCxsnBFRYKI+ogDcpq4AvkUWHlA61PAEdLLg0HCIKfHpzKE8CAAK7MCR1FBgpFKi3AgASgFBNCT8XsOFJqUmplo0AwBmcARY8aCEpORUtAwIbR28AiLi0rICCsfKCOqaELr6zq7nnJ09MP3eIYkEZjSaBYKzebA0zLUwoNAYACCACtgBQVE17PwjkpTthcPtiIwgsgxtY1hwADQINZaCAAfm4kwAjmoCJAAJI0Ok3GRdSrhLRgYhyKQyT7lSrVah1HQAN28UC0dB2LTSJLJ0Ap1NpDKZBFZ7IgXJ5Y35OkFwqIosMZVc5n84P0GwCsAAFsSoMgddyIKI7QhlrCTLArIh-IbIJIEDQCAB3BAotEYuxQfiORamCNsyCMHwAemokB81IM-TdOjo3B8AHEAKIkHzFURAA

使用 flex 布局，使用 uuid 库生成 id ，使用 react hook ， 使用 git ...

这些写了感觉很硬凑，在 xxx 项目中用了 flex 布局又谈不上什么亮点，在专业技能里列出来更好。

熟悉基于 Git 的版本控制和工作流
熟悉现代 CSS 中的 flex grid 布局和传统盒模型