# React (Next.js)

# 🗒️ 原因

• ** 服务端渲染 (SSR)😗* 提升首屏加载速度和 SEO 优化能力，用户体验更好。
• **React 生态系统成熟:** 拥有丰富的第三方库，社区活跃，易于开发和维护。
• ** 组件化设计:** 便于代码重用和团队协作开发。
• 虚拟 DOM+Fiber 架构: 提高运行效率，实现高效的 DOM 操作。

# Tailwind CSS

# 🗒️ 原因

• 实用程序优先: 通过组合实用程序类构建设计系统，易于自定义样式。
• 高生产力: 无需手写 CSS, 直接在标记中添加实用程序类。
• 高度响应式: 基于移动优先设计，自动生成响应式实用程序。
• ** 高度可配置:** 可通过配置文件定制化实用程序样式。

# Nest.js

# 🗒️ 原因

• TypeScript 支持: 静态类型检查，提高代码可维护性和开发效率。
• 模块化设计: 整洁、可测试、可扩展的应用程序架构。
• 依赖注入: 方便管理模块间依赖关系。
• 适配多种传输层: 支持 HTTP、WebSockets、微服务等。

# Rust

# 🗒️ 原因

• 高性能、低资源占用: 面向系统编程，性能接近 C/C++, 占用资源少。
• 安全性强: 所有权机制和借用检查器，避免了内存安全问题。
• 并发编程友好: 基于所有权的并发模型，不用加锁即可编写线程安全代码。
• WebAssembly: 可编译为 WASM, 在 Web 应用中运行，提升性能。

# GraphQL

# 🗒️ 原因

• 灵活、高效的 API 查询: 根据客户端需求定制数据，减少网络传输开销。
• 强类型系统: 类型安全，客户端可预先知晓 API 结构。
• 实时更新: 订阅机制支持服务端实时向客户端推送数据。
• 生态系统丰富: 工具链成熟，有大量开源库可用。

# Vite

# 🗒️ 原因

• 快速冷启动: 通过预捆绑依赖，冷启动时间大幅缩短。
• 按需编译: 仅编译源码中实际使用的部分，减少编译时间。
• 热模块替换 (HMR) 高效: Vite 中的 HMR 传输引用信息，无需完全重载页面。
• Rollup 打包工具: 输出结果高度优化，资源体积更小。

近日我开发了两款 Chrome 插件，一款是关于快速复制 URL 的，另一款是关于知乎屏蔽回答用户的。

# URL Copy

为什么要做这个插件，我不想要老是移动鼠标放到地址栏进行 Ctrl + C 这个操作，我的鼠标我只想让他去有用的地方，其他地方不要去。也许有人会说，你可以用 Ctrl+L + Ctrl+A + Ctrl+C ，这个操作也很麻烦，而且我需要两个手协作才可以完成这个操作，真的很不友好。我只想一个手就搞定。

现在我做的这个插件只需要按下 Shift + Ctrl + X 就可以复制 URL 了，很方便。吐槽一下，Chrome 居然把 Shift + Ctrl + C 快捷键占用了。😌

感谢 Arc 浏览器给我带来的灵感，我直接做了一个抄袭。谁让 Arc 浏览器不发布 Windows 版本呢，虽然我用着 Mac。

插件下载地址：https://github.com/huifer/url-copy

# 知乎 UBlack

为什么要做这个插件，V2EX 网站上看到了一个帖子，在问是否有屏蔽用户回答的插件，主要原因是发现很多技术相关的问题都被卖课的占领了，答非所问，强行回答，文章又臭又长，还一个个排在前面。请问有类似 ublacklist 这样的插件可以利用公共黑名单屏蔽掉这些人吗？

原贴: https://v2ex.com/t/1024481

看到这个信息正好前两日在玩浏览器插件，于是乎马不停蹄的进行实操，整个实操过程还用了 GPT 相关内容，整体还是很顺利的。整个插件开发的周期 2 个小时左右吧（算上广告屏蔽）。

插件的一些不足：

1. 插件需要等 html 全部加载完成后才可以使用，会删除这个 dom 节点。
2. 插件使用过程中需要选中用户的用户名才行，多了识别不了。希望大佬支支招，可以的话 github 上写一个 issues 吧。🤔
3. 有个通讯问题没解决，但是不影响正常使用。🤕

做完了发到交流群，群友告诉我我说可以试试知乎的屏蔽用户功能，需要点到用户详情页面，然后再将其进行屏蔽。我尝试了这个行为，我先将其进行屏蔽了，然后刷新问题内容，还是会有，无法完整的屏蔽这个人。

插件下载地址：https://github.com/huifer/zhihu-ublacklist

最近我在使用 GPT 做一些软件开发，主要开发方向是做 Chrome 插件开发。这个插件的功能是右键获取文本内容然后将其进行屏蔽（知乎问题回答界面，屏蔽某个用户回答）。先说总结，GPT 和 Gemini 给我带来的效率提升是毋庸置疑的，但是还是需要花费较多的时间进行验证，但是这个验证时间和我原本开发的时间来说，是一个很小的时间。

结论：GPT 开发是好事，但是需要有足够的辨识能力，有时候 GPT 也不知道自己再说什么，我也不知道应该如何引导他。

# Gemini 工具

我最开始放入的提示词：

我写了一部分程序，然后放给 gemini，需要让他帮我处理一些内容，提示词内容如下。

我告诉他拿不到这个元素，让他帮我重新处理

他出现问题我又一次进行询问，然后效果还是不理想

在 GEMINI 这个工具使用过程中我发现他对于插件的认知不够好，也许是我不会使用。但是在让他帮我写 Readme 的时候写的方式很棒

# GPT 对 JS 理解不错

在使用 Gemini 的过程中有一点不舒服，然后换到了 GPT3.5 进行一些 DOM 元素的处理，整体看下来效果不错。