From 4c065459528e234ffbd78e16d30749b3de59f8d5 Mon Sep 17 00:00:00 2001 From: muqiuhan Date: Sun, 19 Oct 2025 15:56:17 +0000 Subject: deploy: f1738ca16a5f3a5ced73743a22916b76442ad226 --- search.xml | 276 ++++++++++++++++++++++++++++++------------------------------- 1 file changed, 138 insertions(+), 138 deletions(-) (limited to 'search.xml') diff --git a/search.xml b/search.xml index a93feba8..322305c5 100644 --- a/search.xml +++ b/search.xml @@ -2617,6 +2617,43 @@ A relation table (also sometimes called a JOIN, link or pi

本快速入门文档参照 Turborepo 2.x 官方文档: https://turbo.build/repo/docs
最后一次编辑：二〇二四年九月二十七日下午六点〇七分

+]]> + + Technique + + + + TypeScript With Rust Errors, No Try Catch, Heresy + /2023/04/30/TypeScript-With-Rust-Errors-No-Try-Catch-Heresy/ + +

It’s hard to miss things when you don’t know different things exist

+ +

The first problem is, and personally, I believe it’s the biggest JavaScript problem ever: we don’t know what can throw an error. From a JavaScript error perspective, it’s the same as the following:

+
try {
  let data = “Hello”;
} catch (err) {
  console.error(err);
}
+

JavaScript doesn’t know; JavaScript doesn’t care. You should know.

+

Second thing, this is perfectly viable code:

+
const request = { name: “test”, value: 2n };
const body = JSON.stringify(request);
const response = await fetch("https://example.com", {
  method: “POST”,
  body,
});
if (!response.ok) {
  return;
}
+

No errors, no linters, even though this can break your app.

+

Right now, in my head, I can hear, “What’s the problem, just use try/catch everywhere.” Here comes the third problem: we don’t know which one is thrown. Of course, we can somehow guess by the error message, but what about bigger services/functions with many places where errors can happen? Are you sure you are handling all of them properly with one try/catch?

+
+
let greeting_file_result = File::open(“hello.txt”);  
let greeting_file = match greeting_file_result {  
  Ok(file) => file,  
  Err(error) => panic!("Problem opening the file: {:?}", error),  
};
+

The most verbose of the three shown here and, ironically, the best one. So, first of all, Rust handles the errors using its amazing enums (they are not the same as TypeScript enums!). Without going into detail, what is important here is that it uses an enum called Result with two variants: Ok and Err. As you might guess, Ok holds a value and Err holds…surprise, an error :D.

+

The summary here is that Rust always know where there might be an error. And it force you to deal with it right where it appears (mostly). No hidden ones, no guessing, no breaking app with a surprise face.

+

And this approach is just better. By A MILE.

+

We cannot make TypeScript errors work like the Rust. The limiting factor here is the language itself; it doesn’t have the proper tools to do that.

+

But what we can do is try to make it similar. And make it simple:

+
export type Safe<T> =  
  | {  
    success: true;  
    data: T;  
  }  
  | {  
    success: false;  
    error: string;  
  };
+

we do need a few try/catches. The good thing is we only need about two, not 100,000:

+
export function safe<T>(promise: Promise<T>, err?: string): Promise<Safe<T>>;
export function safe<T>(func: () => T, err?: string): Safe<T>;
export function safe<T>(
  promiseOrFunc: Promise<T> | (() => T),
  err?: string,
): Promise<Safe<T>> | Safe<T> {
  if (promiseOrFunc instanceof Promise) {
    return safeAsync(promiseOrFunc, err);
  }
  return safeSync(promiseOrFunc, err);
}

async function safeAsync<T>(
  promise: Promise<T>, 
  err?: string
): Promise<Safe<T>> {
  try {
    const data = await promise;
    return { data, success: true };
  } catch (e) {
    console.error(e);
    if (err !== undefined) {
      return { success: false, error: err };
    }
    if (e instanceof Error) {
      return { success: false, error: e.message };
    }
    return { success: false, error: "Something went wrong" };
  }
}

function safeSync<T>(
  func: () => T, 
  err?: string
): Safe<T> {
  try {
    const data = func();
    return { data, success: true };
  } catch (e) {
    console.error(e);
    if (err !== undefined) {
      return { success: false, error: err };
    }
    if (e instanceof Error) {
      return { success: false, error: e.message };
    }
    return { success: false, error: "Something went wrong" };
  }
}
+

This is just a wrapper with our Safe type as the return one. But sometimes simple things are all you need. Let’s combine them with the example from above.

+
const request = { name: “test”, value: 2n };  
const body = safe(  
  () => JSON.stringify(request),  
  “Failed to serialize request”,  
);  
if (!body.success) {  
  // handle error (body.error)  
  return;  
}  
const response = await safe(  
  fetch("https://example.com", {  
    method: “POST”,  
    body: body.data,  
  }),  
);  
if (!response.success) {  
  // handle error (response.error)  
  return;  
}  
if (!response.data.ok) {  
  // handle network error  
  return;  
}  
// handle response (body.data)
+

New solution is longer, but it performs better because of the following reasons:

+
    +
  • no try/catch
    • +
  • we handle each error where it occurs
    • +
  • we can specify an error message for a specific function
    • +
  • we have a nice top-to-bottom logic, all errors on top, then only the response at the bottom
    • +
]]> Technique @@ -2660,43 +2697,6 @@ A relation table (also sometimes called a JOIN, link or pi -]]> - - Technique - - - - TypeScript With Rust Errors, No Try Catch, Heresy - /2023/04/30/TypeScript-With-Rust-Errors-No-Try-Catch-Heresy/ - -

It’s hard to miss things when you don’t know different things exist

- -

The first problem is, and personally, I believe it’s the biggest JavaScript problem ever: we don’t know what can throw an error. From a JavaScript error perspective, it’s the same as the following:

-
try {
  let data = “Hello”;
} catch (err) {
  console.error(err);
}
-

JavaScript doesn’t know; JavaScript doesn’t care. You should know.

-

Second thing, this is perfectly viable code:

-
const request = { name: “test”, value: 2n };
const body = JSON.stringify(request);
const response = await fetch("https://example.com", {
  method: “POST”,
  body,
});
if (!response.ok) {
  return;
}
-

No errors, no linters, even though this can break your app.

-

Right now, in my head, I can hear, “What’s the problem, just use try/catch everywhere.” Here comes the third problem: we don’t know which one is thrown. Of course, we can somehow guess by the error message, but what about bigger services/functions with many places where errors can happen? Are you sure you are handling all of them properly with one try/catch?

-
-
let greeting_file_result = File::open(“hello.txt”);  
let greeting_file = match greeting_file_result {  
  Ok(file) => file,  
  Err(error) => panic!("Problem opening the file: {:?}", error),  
};
-

The most verbose of the three shown here and, ironically, the best one. So, first of all, Rust handles the errors using its amazing enums (they are not the same as TypeScript enums!). Without going into detail, what is important here is that it uses an enum called Result with two variants: Ok and Err. As you might guess, Ok holds a value and Err holds…surprise, an error :D.

-

The summary here is that Rust always know where there might be an error. And it force you to deal with it right where it appears (mostly). No hidden ones, no guessing, no breaking app with a surprise face.

-

And this approach is just better. By A MILE.

-

We cannot make TypeScript errors work like the Rust. The limiting factor here is the language itself; it doesn’t have the proper tools to do that.

-

But what we can do is try to make it similar. And make it simple:

-
export type Safe<T> =  
  | {  
    success: true;  
    data: T;  
  }  
  | {  
    success: false;  
    error: string;  
  };
-

we do need a few try/catches. The good thing is we only need about two, not 100,000:

-
export function safe<T>(promise: Promise<T>, err?: string): Promise<Safe<T>>;
export function safe<T>(func: () => T, err?: string): Safe<T>;
export function safe<T>(
  promiseOrFunc: Promise<T> | (() => T),
  err?: string,
): Promise<Safe<T>> | Safe<T> {
  if (promiseOrFunc instanceof Promise) {
    return safeAsync(promiseOrFunc, err);
  }
  return safeSync(promiseOrFunc, err);
}

async function safeAsync<T>(
  promise: Promise<T>, 
  err?: string
): Promise<Safe<T>> {
  try {
    const data = await promise;
    return { data, success: true };
  } catch (e) {
    console.error(e);
    if (err !== undefined) {
      return { success: false, error: err };
    }
    if (e instanceof Error) {
      return { success: false, error: e.message };
    }
    return { success: false, error: "Something went wrong" };
  }
}

function safeSync<T>(
  func: () => T, 
  err?: string
): Safe<T> {
  try {
    const data = func();
    return { data, success: true };
  } catch (e) {
    console.error(e);
    if (err !== undefined) {
      return { success: false, error: err };
    }
    if (e instanceof Error) {
      return { success: false, error: e.message };
    }
    return { success: false, error: "Something went wrong" };
  }
}
-

This is just a wrapper with our Safe type as the return one. But sometimes simple things are all you need. Let’s combine them with the example from above.

-
const request = { name: “test”, value: 2n };  
const body = safe(  
  () => JSON.stringify(request),  
  “Failed to serialize request”,  
);  
if (!body.success) {  
  // handle error (body.error)  
  return;  
}  
const response = await safe(  
  fetch("https://example.com", {  
    method: “POST”,  
    body: body.data,  
  }),  
);  
if (!response.success) {  
  // handle error (response.error)  
  return;  
}  
if (!response.data.ok) {  
  // handle network error  
  return;  
}  
// handle response (body.data)
-

New solution is longer, but it performs better because of the following reasons:

-
    -
  • no try/catch
    • -
  • we handle each error where it occurs
    • -
  • we can specify an error message for a specific function
    • -
  • we have a nice top-to-bottom logic, all errors on top, then only the response at the bottom
    • -
]]> Technique @@ -3624,6 +3624,18 @@ NestJS 依赖其底层 HTTP 适配器（默认为 Express）来解析传入的

虽然我早已不强求世界上有这么一个人，

但我会一直等待，甚至期待你的到来。

我叫韩暮秋，幸会。

+]]> + + gallery + + + + 二〇二五年二月二十四日 + /2025/02/24/%E4%BA%8C%E3%80%87%E4%BA%8C%E4%BA%94%E5%B9%B4%E4%BA%8C%E6%9C%88%E4%BA%8C%E5%8D%81%E5%9B%9B%E6%97%A5/ + 街上的人躲进建筑，道路上的车变得缓慢。路边的黑猫坐在屋檐下张望，在雨天，它也有了思考的地方与时间。除了淅淅沥沥的雨声再无其他。

+

衣服买大了，他们走路好急，地铁上只有老人没看手机，天怎么黑那么快是我起晚了吗，那个蹦蹦跳跳的女孩耳机里在听什么歌，我还在原地吗，我要再等等吗。

+

家就像厚酒之后突然明晰的想象，时间不语，只是沉默，我沉默地走进时间，看着我和你的年龄相差越来越小。

+

这雨天，世界都温柔的可以掐出水来。

]]> gallery @@ -4030,6 +4042,15 @@ NestJS 依赖其底层 HTTP 适配器（默认为 Express）来解析传入的 二零二一年二月十四日 /2021/02/14/%E4%BA%8C%E9%9B%B6%E4%BA%8C%E4%B8%80%E5%B9%B4%E4%BA%8C%E6%9C%88%E5%8D%81%E5%9B%9B%E6%97%A5/ 把酒从铁罐子里面赶出来，赶到脸上，被眼泪驱逐，混着干涸的血，揉着尘埃，尝尽酸甜苦辣

+]]> + + gallery + + + + 二零二三年一月二十一日 + /2023/01/21/%E4%BA%8C%E9%9B%B6%E4%BA%8C%E4%B8%89%E5%B9%B4%E4%B8%80%E6%9C%88%E4%BA%8C%E5%8D%81%E4%B8%80%E6%97%A5/ + 我踏着烟火若隐若现， 我生来就是为了把这个世界的消息带到下一个世界去。

]]> gallery @@ -4048,15 +4069,6 @@ NestJS 依赖其底层 HTTP 适配器（默认为 Express）来解析传入的

韩暮秋，息止安所。

-]]> - - gallery - - - - 二零二三年一月二十一日 - /2023/01/21/%E4%BA%8C%E9%9B%B6%E4%BA%8C%E4%B8%89%E5%B9%B4%E4%B8%80%E6%9C%88%E4%BA%8C%E5%8D%81%E4%B8%80%E6%97%A5/ - 我踏着烟火若隐若现， 我生来就是为了把这个世界的消息带到下一个世界去。

]]> gallery @@ -4095,20 +4107,20 @@ NestJS 依赖其底层 HTTP 适配器（默认为 Express）来解析传入的 - 二零二三年二月二十六日 - /2023/02/26/%E4%BA%8C%E9%9B%B6%E4%BA%8C%E4%B8%89%E5%B9%B4%E4%BA%8C%E6%9C%88%E4%BA%8C%E5%8D%81%E5%85%AD%E6%97%A5/ - 翻滚的热汤接过焰火的能量把周围的蒸汽撕开一道裂缝，透过缝隙我见到一对爱人的时空交织在未来，他们幸运的错开孤独，人们举起手中的酒杯，祝因果与命运缠绵之人幸福

+ 二零二三年二月二十五日 + /2023/02/25/%E4%BA%8C%E9%9B%B6%E4%BA%8C%E4%B8%89%E5%B9%B4%E4%BA%8C%E6%9C%88%E4%BA%8C%E5%8D%81%E4%BA%94%E6%97%A5/ + 我无法表达出我所处的时间概念，只是我的实际感受，睁眼闭眼就是过去和未来。

+

我闭上眼睛就能感受到不知道是过去还是未来的某个时刻，阳光从睫毛的缝隙钻进我的眼睛，闭上眼睛是一片光圈，我看不清周围，我也不需要看清周围，我只需要感觉到整个世界给我最热烈的拥抱。

+

我睁开眼睛也能感受到过去还是未来的某个时刻，我开车穿梭在灰蒙蒙的细雨笼罩中的城市，细雨模糊了整个城市的夜空，在我的车窗前汇成水珠晕开了红绿灯的光线，再被雨刮器一扫而空。

]]> gallery - 二零二三年二月二十五日 - /2023/02/25/%E4%BA%8C%E9%9B%B6%E4%BA%8C%E4%B8%89%E5%B9%B4%E4%BA%8C%E6%9C%88%E4%BA%8C%E5%8D%81%E4%BA%94%E6%97%A5/ - 我无法表达出我所处的时间概念，只是我的实际感受，睁眼闭眼就是过去和未来。

-

我闭上眼睛就能感受到不知道是过去还是未来的某个时刻，阳光从睫毛的缝隙钻进我的眼睛，闭上眼睛是一片光圈，我看不清周围，我也不需要看清周围，我只需要感觉到整个世界给我最热烈的拥抱。

-

我睁开眼睛也能感受到过去还是未来的某个时刻，我开车穿梭在灰蒙蒙的细雨笼罩中的城市，细雨模糊了整个城市的夜空，在我的车窗前汇成水珠晕开了红绿灯的光线，再被雨刮器一扫而空。

+ 二零二三年二月二十六日 + /2023/02/26/%E4%BA%8C%E9%9B%B6%E4%BA%8C%E4%B8%89%E5%B9%B4%E4%BA%8C%E6%9C%88%E4%BA%8C%E5%8D%81%E5%85%AD%E6%97%A5/ + 翻滚的热汤接过焰火的能量把周围的蒸汽撕开一道裂缝，透过缝隙我见到一对爱人的时空交织在未来，他们幸运的错开孤独，人们举起手中的酒杯，祝因果与命运缠绵之人幸福

]]> gallery @@ -4174,6 +4186,19 @@ NestJS 依赖其底层 HTTP 适配器（默认为 Express）来解析传入的

接收到的评论不必急于改变，先存起来，让它们陪着自己，跟着时间走，路上会慢慢的和其他的事情连结起来，这样就能择其善者而从之，其不善者而改之了。

应当早日从这喧扰的世界冷静下来，让脑子里满是憧憬和情爱的灵魂得到一丝陈酿，理性点抬头看看世界上方的二氧化碳，自己晃晃头打破能回到最初的样子再重来的梦。

爱你们。

+]]> + + gallery + + + + 二零二三年十一月六日 + /2023/11/06/%E4%BA%8C%E9%9B%B6%E4%BA%8C%E4%B8%89%E5%B9%B4%E5%8D%81%E4%B8%80%E6%9C%88%E5%85%AD%E6%97%A5/ + 寒风打得他踉跄地摔进田野中，他颤抖着，疑惑的抬起头，云层捂住了月亮，摇曳着露出一角烛火般的月光，烛火同他的身体一般颤抖，那是落日的余晖，也是等待朝阳的希望。

+

世界同可怜的孩子一起闭上了眼睛，世界不那么开心，但是

+
+

这个世界，我真的爱你

+
]]> gallery @@ -4192,19 +4217,6 @@ NestJS 依赖其底层 HTTP 适配器（默认为 Express）来解析传入的

岁月中的某个文明中的某个人，曾经也骑着骆驼向远方，又是哪个人，吟着佛门心语站在我身旁，我听见大漠的念经声。

我不是个有耐心的人， 抄经书对我来说是种折磨， 我只能选择把经文抄在大地上， 黄沙上， 用自己的双腿一点点写， 用耳去倾听狂风卷积的声音。

我生来就是为了把这个世界的消息和秘密带到下一个世界去。

-]]> - - gallery - - - - 二零二三年十一月六日 - /2023/11/06/%E4%BA%8C%E9%9B%B6%E4%BA%8C%E4%B8%89%E5%B9%B4%E5%8D%81%E4%B8%80%E6%9C%88%E5%85%AD%E6%97%A5/ - 寒风打得他踉跄地摔进田野中，他颤抖着，疑惑的抬起头，云层捂住了月亮，摇曳着露出一角烛火般的月光，烛火同他的身体一般颤抖，那是落日的余晖，也是等待朝阳的希望。

-

世界同可怜的孩子一起闭上了眼睛，世界不那么开心，但是

-
-

这个世界，我真的爱你

-
]]> gallery @@ -4264,18 +4276,18 @@ NestJS 依赖其底层 HTTP 适配器（默认为 Express）来解析传入的 - 二零二二年十二月三十一日 - /2022/12/31/%E4%BA%8C%E9%9B%B6%E4%BA%8C%E4%BA%8C%E5%B9%B4%E5%8D%81%E4%BA%8C%E6%9C%88%E4%B8%89%E5%8D%81%E4%B8%80%E6%97%A5/ - 我要做时间富人，肆意挥霍，飘在世界上空，什么都不做，静静看着周遭的一切，命运给我什么我就接着，命运拿走什么我就看着，到模糊不见，到夜色如烟。

+ 二零二二年十一月月三日 + /2022/11/03/%E4%BA%8C%E9%9B%B6%E4%BA%8C%E4%BA%8C%E5%B9%B4%E5%8D%81%E4%B8%80%E6%9C%88%E6%9C%88%E4%B8%89%E6%97%A5/ + 我独自冒着冷风，去薄霜铺地的林子里，为听鸟语，为盼朝阳，为寻泥土里渐次苏醒的花草，但春信不至。我是如此单独而完整，在无数个夜晚，独自顶着冷风 伫立在老橘树下的桥头，只为听一曲夜莺的哀歌，倚暖了石栏上的青苔，青苔凉透了我的心坎，但夜莺不来，夜莺不来啊。

]]> gallery - 二零二二年十一月月三日 - /2022/11/03/%E4%BA%8C%E9%9B%B6%E4%BA%8C%E4%BA%8C%E5%B9%B4%E5%8D%81%E4%B8%80%E6%9C%88%E6%9C%88%E4%B8%89%E6%97%A5/ - 我独自冒着冷风，去薄霜铺地的林子里，为听鸟语，为盼朝阳，为寻泥土里渐次苏醒的花草，但春信不至。我是如此单独而完整，在无数个夜晚，独自顶着冷风 伫立在老橘树下的桥头，只为听一曲夜莺的哀歌，倚暖了石栏上的青苔，青苔凉透了我的心坎，但夜莺不来，夜莺不来啊。

+ 二零二二年十二月三十一日 + /2022/12/31/%E4%BA%8C%E9%9B%B6%E4%BA%8C%E4%BA%8C%E5%B9%B4%E5%8D%81%E4%BA%8C%E6%9C%88%E4%B8%89%E5%8D%81%E4%B8%80%E6%97%A5/ + 我要做时间富人，肆意挥霍，飘在世界上空，什么都不做，静静看着周遭的一切，命运给我什么我就接着，命运拿走什么我就看着，到模糊不见，到夜色如烟。

]]> gallery @@ -4356,6 +4368,20 @@ NestJS 依赖其底层 HTTP 适配器（默认为 Express）来解析传入的 Technique + + 儿童新型冠状病毒Omicron株和肺炎支原体混合感染重症肺炎1例 + /2023/10/25/%E5%84%BF%E7%AB%A5%E6%96%B0%E5%9E%8B%E5%86%A0%E7%8A%B6%E7%97%85%E6%AF%92Omicron%E6%A0%AA%E5%92%8C%E8%82%BA%E7%82%8E%E6%94%AF%E5%8E%9F%E4%BD%93%E6%B7%B7%E5%90%88%E6%84%9F%E6%9F%93%E9%87%8D%E7%97%87%E8%82%BA%E7%82%8E1%E4%BE%8B/ + 患儿 男, 3 岁 10 月龄,因“间歇发热 2 周伴咳嗽、气促”入上海交通大学医学院附属仁济医院(南部院区)定点医院隔离病房。
+患儿病初发热,确诊为新型冠状病毒肺炎(简称新冠肺炎),热退 2d 再次持续高热>3d 伴气促、吸气性凹陷,胸部 CT 示右肺下叶片状密度影,诊断“重型新冠肺炎”,行支气管镜肺泡灌洗,宏基因组病原检测确诊为混合肺炎支原体感染,治疗好转出院。
+提示临床医生诊治重型新冠肺炎时需警惕混合感染

+ +]]> + + Medicine + + 冬季咳嗽辨别指南 /2023/10/22/%E5%86%AC%E5%AD%A3%E5%92%B3%E5%97%BD%E8%BE%A8%E5%88%AB%E6%8C%87%E5%8D%97/ @@ -4433,20 +4459,6 @@ NestJS 依赖其底层 HTTP 适配器（默认为 Express）来解析传入的 Life - - 儿童新型冠状病毒Omicron株和肺炎支原体混合感染重症肺炎1例 - /2023/10/25/%E5%84%BF%E7%AB%A5%E6%96%B0%E5%9E%8B%E5%86%A0%E7%8A%B6%E7%97%85%E6%AF%92Omicron%E6%A0%AA%E5%92%8C%E8%82%BA%E7%82%8E%E6%94%AF%E5%8E%9F%E4%BD%93%E6%B7%B7%E5%90%88%E6%84%9F%E6%9F%93%E9%87%8D%E7%97%87%E8%82%BA%E7%82%8E1%E4%BE%8B/ - 患儿 男, 3 岁 10 月龄,因“间歇发热 2 周伴咳嗽、气促”入上海交通大学医学院附属仁济医院(南部院区)定点医院隔离病房。
-患儿病初发热,确诊为新型冠状病毒肺炎(简称新冠肺炎),热退 2d 再次持续高热>3d 伴气促、吸气性凹陷,胸部 CT 示右肺下叶片状密度影,诊断“重型新冠肺炎”,行支气管镜肺泡灌洗,宏基因组病原检测确诊为混合肺炎支原体感染,治疗好转出院。
-提示临床医生诊治重型新冠肺炎时需警惕混合感染

- -]]> - - Medicine - - 发热及超高热危象 /2023/06/17/%E5%8F%91%E7%83%AD%E5%8F%8A%E8%B6%85%E9%AB%98%E7%83%AD%E5%8D%B1%E8%B1%A1/ @@ -4835,6 +4847,33 @@ NestJS 依赖其底层 HTTP 适配器（默认为 Express）来解析传入的 Design + + 实时搜索中的防抖函数 + /2025/02/10/%E5%AE%9E%E6%97%B6%E6%90%9C%E7%B4%A2%E4%B8%AD%E7%9A%84%E9%98%B2%E6%8A%96%E5%87%BD%E6%95%B0/ + 在实现实时搜索功能时，通常会使用输入框的事件监听器来捕获用户的输入变化，并在输入变化时发送搜索请求。为了避免过多的请求导致服务器负担过重，通常会使用“防抖”（debounce）技术来控制请求的频率。

+

实现步骤

+
    +
  1. 监听输入框的变化：使用input事件监听器来捕获用户的输入变化。
    2. +
  2. 防抖处理：使用防抖函数来限制请求的频率。防抖函数会在用户停止输入一段时间后才发送请求。
    3. +
  3. 发送请求：在防抖函数中调用搜索请求。
    4. +
+

防抖函数示例

+

以下是一个简单的防抖函数示例：

+
function debounce(func, wait) {
  let timeout;
  return function(...args) {
    const context = this;
    clearTimeout(timeout);
    timeout = setTimeout(() => func.apply(context, args), wait);
  };
}
+

实现实时搜索

+

假设你有一个输入框用于搜索患者：

+
<script>
  import { onMount } from 'svelte';
  import { patientsStore } from '$lib/stores/patients.svelte';

  let searchTerm = '';

  // 防抖函数
  function debounce(func, wait) {
    let timeout;
    return function(...args) {
      const context = this;
      clearTimeout(timeout);
      timeout = setTimeout(() => func.apply(context, args), wait);
    };
  }

  // 搜索函数
  const searchPatients = debounce(async (term) => {
    if (term) {
      // 发送搜索请求
      const response = await fetch(`/api/search-patients?query=${term}`);
      const data = await response.json();
      patientsStore.mbglPatients = data;
    } else {
      // 清空搜索结果或恢复默认数据
      patientsStore.mbglPatients = [];
    }
  }, 300); // 300ms 的防抖时间

  // 监听输入框变化
  function handleInput(event) {
    searchTerm = event.target.value;
    searchPatients(searchTerm);
  }
</script>

<input type="text" placeholder="搜索患者..." on:input={handleInput} bind:value={searchTerm} />
+

请求发送间隔

+
    +
  • 防抖时间：通常设置为 300ms 到 500ms 之间。这个时间足够让用户完成输入并减少不必要的请求。
    • +
  • 考虑用户体验：防抖时间过短可能导致过多请求，过长则可能让用户感到延迟。300ms 是一个常用的折中值。
    • +
+

通过这种方式，你可以实现一个高效的实时搜索功能，既能保证用户体验，又能减少服务器的负担。

+]]> + + Technique + + 急诊与灾难医学--烧伤 /2024/01/25/%E6%80%A5%E8%AF%8A%E4%B8%8E%E7%81%BE%E9%9A%BE%E5%8C%BB%E5%AD%A6-%E7%83%A7%E4%BC%A4/ @@ -4985,33 +5024,6 @@ NestJS 依赖其底层 HTTP 适配器（默认为 Express）来解析传入的 Medicine - - 实时搜索中的防抖函数 - /2025/02/10/%E5%AE%9E%E6%97%B6%E6%90%9C%E7%B4%A2%E4%B8%AD%E7%9A%84%E9%98%B2%E6%8A%96%E5%87%BD%E6%95%B0/ - 在实现实时搜索功能时，通常会使用输入框的事件监听器来捕获用户的输入变化，并在输入变化时发送搜索请求。为了避免过多的请求导致服务器负担过重，通常会使用“防抖”（debounce）技术来控制请求的频率。

-

实现步骤

-
    -
  1. 监听输入框的变化：使用input事件监听器来捕获用户的输入变化。
    2. -
  2. 防抖处理：使用防抖函数来限制请求的频率。防抖函数会在用户停止输入一段时间后才发送请求。
    3. -
  3. 发送请求：在防抖函数中调用搜索请求。
    4. -
-

防抖函数示例

-

以下是一个简单的防抖函数示例：

-
function debounce(func, wait) {
  let timeout;
  return function(...args) {
    const context = this;
    clearTimeout(timeout);
    timeout = setTimeout(() => func.apply(context, args), wait);
  };
}
-

实现实时搜索

-

假设你有一个输入框用于搜索患者：

-
<script>
  import { onMount } from 'svelte';
  import { patientsStore } from '$lib/stores/patients.svelte';

  let searchTerm = '';

  // 防抖函数
  function debounce(func, wait) {
    let timeout;
    return function(...args) {
      const context = this;
      clearTimeout(timeout);
      timeout = setTimeout(() => func.apply(context, args), wait);
    };
  }

  // 搜索函数
  const searchPatients = debounce(async (term) => {
    if (term) {
      // 发送搜索请求
      const response = await fetch(`/api/search-patients?query=${term}`);
      const data = await response.json();
      patientsStore.mbglPatients = data;
    } else {
      // 清空搜索结果或恢复默认数据
      patientsStore.mbglPatients = [];
    }
  }, 300); // 300ms 的防抖时间

  // 监听输入框变化
  function handleInput(event) {
    searchTerm = event.target.value;
    searchPatients(searchTerm);
  }
</script>

<input type="text" placeholder="搜索患者..." on:input={handleInput} bind:value={searchTerm} />
-

请求发送间隔

-
    -
  • 防抖时间：通常设置为 300ms 到 500ms 之间。这个时间足够让用户完成输入并减少不必要的请求。
    • -
  • 考虑用户体验：防抖时间过短可能导致过多请求，过长则可能让用户感到延迟。300ms 是一个常用的折中值。
    • -
-

通过这种方式，你可以实现一个高效的实时搜索功能，既能保证用户体验，又能减少服务器的负担。

-]]> - - Technique - - 慢性肺源性心脏病 /2024/01/23/%E6%85%A2%E6%80%A7%E8%82%BA%E6%BA%90%E6%80%A7%E5%BF%83%E8%84%8F%E7%97%85/ @@ -5306,18 +5318,6 @@ NestJS 依赖其底层 HTTP 适配器（默认为 Express）来解析传入的 Life - - 二〇二五年二月二十四日 - /2025/02/24/%E4%BA%8C%E3%80%87%E4%BA%8C%E4%BA%94%E5%B9%B4%E4%BA%8C%E6%9C%88%E4%BA%8C%E5%8D%81%E5%9B%9B%E6%97%A5/ - 街上的人躲进建筑，道路上的车变得缓慢。路边的黑猫坐在屋檐下张望，在雨天，它也有了思考的地方与时间。除了淅淅沥沥的雨声再无其他。

-

衣服买大了，他们走路好急，地铁上只有老人没看手机，天怎么黑那么快是我起晚了吗，那个蹦蹦跳跳的女孩耳机里在听什么歌，我还在原地吗，我要再等等吗。

-

家就像厚酒之后突然明晰的想象，时间不语，只是沉默，我沉默地走进时间，看着我和你的年龄相差越来越小。

-

这雨天，世界都温柔的可以掐出水来。

-]]> - - gallery - - 直系血亲之间不能直接输血 /2024/08/12/%E7%9B%B4%E7%B3%BB%E8%A1%80%E4%BA%B2%E4%B9%8B%E9%97%B4%E4%B8%8D%E8%83%BD%E7%9B%B4%E6%8E%A5%E8%BE%93%E8%A1%80/ @@ -5561,18 +5561,6 @@ NestJS 依赖其底层 HTTP 适配器（默认为 Express）来解析传入的
  • https://zhuanlan.zhihu.com/p/140951268
  • https://www.zhihu.com/question/480023755
    • -]]> - - Life - -     - - 什么玩意儿都是 - /2024/09/07/%E7%BB%99%E5%AD%A9%E5%AD%90%E4%BB%AC%E7%9A%84%E8%AF%9D/ - 那些自古流传至今的至理名言，如无证实都不可信。今天人人称道的真理，明天却有可能被证实为谬论；有些人被这种云山雾罩的谬论遮蔽了双眼，还以为那是会为他们的土地带来甘露的云雨。

    -

    那些古人们认为不可能办到的事，我们要敢于尝试和创新，只有这样，才能发现是否是可以做到的。古人有古人的办法，新人有新人的办法。古人只知道不断添柴就可以让火苗不灭，而新人却可以在火车锅炉中放点干柴就可以让火车绕着地球跑。

    -

    对于年势已高的老人家而言，不能仅凭年龄就说自己有资格成为年轻人的老师，因为他所失去的要比得到的多得多。任何人都有权怀疑，那些最聪明的人是否真正发现了生活的价值。

    -

    说实话，老一辈人并没有什么至关重要的忠告留给年轻人，他们的生活经验如此不完美，他们的人生因为某种个人原因过得如此悲惨失败。也许阅历中还给了他们一些有悖于那种经验的信心，可惜他们已经不再年轻。我在这世上已经活了二十年零六天，却从没在我的长辈那里得到过一个有价值的忠告或建议。他们讲不出什么有意义的事情，却总是说一些不得要领的话来教训我。这就是生活，一个在很大程度上我并未尝试过的实验；他们尝试过了，对我来说却毫无益处。

    ]]>     Life @@ -5590,6 +5578,18 @@ NestJS 依赖其底层 HTTP 适配器（默认为 Express）来解析传入的 Medicine     + + 什么玩意儿都是 + /2024/09/07/%E7%BB%99%E5%AD%A9%E5%AD%90%E4%BB%AC%E7%9A%84%E8%AF%9D/ + 那些自古流传至今的至理名言，如无证实都不可信。今天人人称道的真理，明天却有可能被证实为谬论；有些人被这种云山雾罩的谬论遮蔽了双眼，还以为那是会为他们的土地带来甘露的云雨。

    +

    那些古人们认为不可能办到的事，我们要敢于尝试和创新，只有这样，才能发现是否是可以做到的。古人有古人的办法，新人有新人的办法。古人只知道不断添柴就可以让火苗不灭，而新人却可以在火车锅炉中放点干柴就可以让火车绕着地球跑。

    +

    对于年势已高的老人家而言，不能仅凭年龄就说自己有资格成为年轻人的老师，因为他所失去的要比得到的多得多。任何人都有权怀疑，那些最聪明的人是否真正发现了生活的价值。

    +

    说实话，老一辈人并没有什么至关重要的忠告留给年轻人，他们的生活经验如此不完美，他们的人生因为某种个人原因过得如此悲惨失败。也许阅历中还给了他们一些有悖于那种经验的信心，可惜他们已经不再年轻。我在这世上已经活了二十年零六天，却从没在我的长辈那里得到过一个有价值的忠告或建议。他们讲不出什么有意义的事情，却总是说一些不得要领的话来教训我。这就是生活，一个在很大程度上我并未尝试过的实验；他们尝试过了，对我来说却毫无益处。

    +]]>     + + Life + +     肝功能检查化验单阅读指南 /2023/10/13/%E8%82%9D%E5%8A%9F%E8%83%BD%E6%A3%80%E6%9F%A5%E5%8C%96%E9%AA%8C%E5%8D%95/ -- cgit v1.2.3