estel/estel_docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

转移blog上所有日志. 添加nuxt.config里高亮配置

Browse Source
This commit is contained in:
estel
2025-08-07 22:18:31 +08:00
parent 6bafa4d12d
commit 8e66c0fc56
12 changed files with 1760 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
content/blog/1.技术栈/10.从Supabase迁移到Appwrite.md Normal file
View File

@@ -0,0 +1,49 @@
---
title: 从Supabase迁移到Appwrite
description: AI 扩写
date: 2025-07-01
img: https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250623164451378.png
navigation:
icon: simple-icons:supabase
---
## 最初的技术选型
去年春节前开发AI平台时，我在后端服务的选择上——Github社区有两个优秀的开源项目：Supabase和Appwrite。
**当时的决策因素**：
1. **社区热度**：Supabase的Star数量明显更多
2. **UI设计**：后台管理界面的配色和布局更符合我的审美
3. **命名偏好**：单纯喜欢"Supabase"这个名字的科技感
4. **商业化支持**：国内有memfire cloud这样的二开商业项目
5. **退出策略**：不想自托管时可以有现成的过渡方案
## 使用后的痛点
随着项目的深入开发，我逐渐感受到了一些问题：
- **系统太重**：Supabase的"全家桶"式设计带来了不必要的复杂度
- **功能过剩**：很多内置功能在项目中根本没有用到
- **维护成本**：自托管的运维负担超出预期
## Appwrite
上个月Appwrite发布的**Sites功能**让我眼前一亮——这个对标Vercel的新功能完全改变了我对它的认知。经过重新评估：
✅ 更轻量的架构
✅ 恰到好处的功能集
✅ 持续创新的能力
## 迁移计划
现在已经着手准备后端迁移：
1. 收集双方的SDK文档
2. 制定cursor-rules转换规则
3. 利用AI辅助代码转换
**嘿，这告诉我们**：
技术选型时除了看表面参数，更应该深入评估：
- 项目的实际需求
- 长期维护成本
- 技术栈的发展潜力
这次迁移虽然会带来短期工作量，但从长期来看绝对是值得的！

109
content/blog/1.技术栈/11.Linux 系统 Swap 分区配置指南.md Normal file
View File

@@ -0,0 +1,109 @@
---
title: Linux 系统 Swap 分区配置指南
description: 在云服务器上配置Swap分区
date: 2025-07-10
img: https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250623214305360.png
navigation:
icon: simple-icons:linux
---
## **1. Swap 分区简介**
Swap（交换分区）是 Linux 系统用来扩展内存的一种机制。当物理内存（RAM）耗尽时，操作系统会将部分不活跃的内存页（inactive memory）移至 Swap 分区，避免 **OOM（Out Of Memory）** 错误导致的服务崩溃。
### **Swap 分区的适用场景**
✅ **内存不足时**：Swap 可使系统暂存部分数据，防止进程被强制终止
✅ **突发高负载时**：避免系统因短时内存不足而崩溃
❌ **SSD/高性能盘场景**：频繁 Swap 会导致 I/O 瓶颈，影响性能
❌ **数据库/高性能应用**：Swap 会降低内存访问速度，建议直接增加物理内存
---
## **2. 查看当前 Swap 配置**
**检查当前是否已启用 Swap：**
```bash
swapon --show
```
- **无输出**：表示未配置 Swap 分区
- **有输出**：显示已启用的 Swap 设备及其大小
---
## **3. 配置 Swap 分区**
### **（1）创建 Swap 文件（推荐）**
Swap 可以基于 **分区** 或 **文件**，推荐使用文件方式（更灵活）。
```bash
# 创建一个 1GB 的 Swap 文件（可按需调整大小）
sudo dd if=/dev/zero of=/swapfile bs=1M count=1024
# 确保该文件只能由 root 访问
sudo chmod 600 /swapfile
# 将文件转换为 Swap 格式
sudo mkswap /swapfile
```
> ⚠️ **注意**：
> - 如果 `mkswap` 报错 **`swap area needs to be at least 40 KiB`**，说明文件过小，需调整 `bs=1M count=1024`（1GB）。
> - 生产环境建议 Swap 大小 = **1~2 倍物理内存**（如 4GB 内存可配 4~8GB Swap）。
### **（2）启用 Swap 分区**
```bash
sudo swapon /swapfile
```
验证是否生效：
```bash
free -h # 查看 Swap 使用情况
```
### **（3）设置开机自动挂载**
在 `/etc/fstab` 中追加配置：
```bash
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
```
验证配置：
```bash
cat /etc/fstab | grep swap
```
---
## **4. 调整内存管理策略（可选）**
默认情况下，Linux 倾向于使用物理内存而非 Swap。
若希望 **减少 Swap 使用**（避免频繁 I/O），可调整 `vm.swappiness`（推荐值：10~60）：
```bash
# 查看当前值（默认60）
cat /proc/sys/vm/swappiness
# 临时调整
sudo sysctl vm.swappiness=10
# 永久生效
echo "vm.swappiness=10" >> /etc/sysctl.conf
```
> **参数说明**：
> - `0`：尽量不使用 Swap（可能导致 OOM）
> - `10`：低内存时少量使用
> - `60`：默认值
---
## **5. 关闭 Swap（如需）**
```bash
swapoff /swapfile # 停止 Swap
rm -f /swapfile # 删除 Swap 文件
sed -i '/swapfile/d' /etc/fstab # 移除 fstab 中的配置
```
---
## **6. 云服务器（ECS）注意事项**
- **普通云盘**：不建议用 Swap，因其 I/O 性能较差，易引发性能问题
- **SSD/高效云盘**：可适当启用 Swap，但要避免频繁交换
- **最优方案**：**升级实例规格**，直接增加物理内存
---
🎯 **总结**
- **Swap 是临时方案**，长期内存不足仍需扩容物理内存
- **监控 Swap 使用**，避免频繁触发磁盘 I/O
- **高性能应用建议禁用 Swap**（如 Redis、MySQL）

213
content/blog/1.技术栈/12.Nuxt3 代码规范.md Normal file
View File

@@ -0,0 +1,213 @@
---
title: Nuxt3 代码规范
description: 这是一份提供给AI大模型的Nuxt3框架规范、编程标准，可以有效提高Cursor等大模型对Nuxt.js框架的编写能力。
date: 2025-07-12
img: https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250624125918171.png
navigation:
icon: simple-icons:nuxtdotjs
---
## 概述
这是一份提供给AI大模型的Nuxt3框架规范、编程标准，可以有效提高Cursor等大模型对Nuxt.js框架的编写能力。
---
description: 本规则为 Nuxt.js 项目提供全面的最佳实践和编码标准，涵盖代码组织、性能、安全性、测试和常见陷阱。旨在确保 Nuxt.js 应用程序的可维护性、可扩展性和安全性。
globs: *.vue,*.js,*.ts,*.mjs,*.mts,*.jsx,*.tsx,*.config.js,*.config.ts
---
- **启用 ESLint 支持：** 使用 `@nuxt/eslint` 模块来配置项目感知的 ESLint。这确保代码质量和一致性。
- 运行 `npx nuxi module add eslint` 添加模块。
- 根据需要自定义生成的 `eslint.config.mjs` 文件。
- **采用 Nuxt.js 模块：** 利用 Nuxt.js 模块来封装功能并维护干净的代码库。在实现自定义解决方案之前先探索现有模块（例如，用于服务端身份验证的 `@nuxt/auth`）。
- **约定优于配置：** 遵循 Nuxt.js 约定来简化开发和协作。除非绝对必要，否则避免偏离约定。
- **高效利用 Nuxt 布局：** 为多个页面共享的组件创建可重用布局，以确保一致性并节省开发时间。布局位于 `layouts/` 目录中。
- **使用 Pinja 管理状态：** 使用 Pinia 进行状态管理。根据功能或特性组织 store 模块，以提高可维护性。
- **将页面分解为组件：** 将页面分解为小的、可重用的组件，以增强可维护性、可测试性和可重用性。每个组件都应该有单一责任。
- **明智地利用 Nuxt 插件：** 使用 Nuxt 插件在 Vue.js 初始化之前运行代码或添加全局功能。注意插件对性能的影响。插件位于 `plugins/` 目录中。
- **针对 SEO 和性能进行优化：** 利用 Nuxt.js 的服务端渲染 (SSR) 来优化 SEO。为图片实现懒加载并优化资源以最小化初始加载时间。使用 Lighthouse 等工具识别性能瓶颈。
- **实现错误处理和验证：** 实现强大的错误处理和验证机制，以提供无缝的用户体验。使用 Nuxt.js 中间件拦截请求和响应进行错误处理和数据验证。
- **为代码编写文档：** 使用 JSDoc 等工具为组件、模块和自定义函数提供清晰简洁的文档。
- **拥抱测试：** 使用 Jest、Vue Test Utils 和 Vitest 等工具编写单元测试、集成测试和端到端测试。
## 1. 代码组织和结构：
- **目录结构：**
- `components/`：可重用的 Vue 组件。
- `composables/`：可重用的组合式函数。
- `layouts/`：应用程序布局。
- `middleware/`：路由中间件。
- `pages/`：应用程序页面（路由定义）。
- `plugins/`：Nuxt.js 插件。
- `server/`：API 路由和服务端逻辑。
- `static/`：静态资源（例如，图片、字体）。
- `store/`：Pinia stores（可选，但推荐）。
- `utils/`：工具函数。
- **文件命名约定：**
- 组件：`PascalCase.vue`（例如，`MyComponent.vue`）
- 组合式函数：`usePascalCase.js` 或 `usePascalCase.ts`（例如，`useCounter.js`）
- 布局：`kebab-case.vue`（例如，`default.vue` 或 `custom-layout.vue`）
- 页面：`kebab-case.vue`（例如，`index.vue`、`about.vue`、`product-details.vue`）
- 插件：`kebab-case.js` 或 `kebab-case.ts`（例如，`analytics.js`）
- Stores：`kebab-case.js` 或 `kebab-case.ts`（例如，`user-store.js`）
- 工具函数：`camelCase.js` 或 `camelCase.ts`（例如，`formatDate.js`）
- **模块组织：**
- 将相关功能分组到单独的模块中。
- 在 `nuxt.config.js` 或 `nuxt.config.ts` 中使用 `@nuxt/modules` 数组注册模块。
- 创建自定义模块来封装复杂逻辑。
- **组件架构：**
- 优先使用组合而非继承。
- 对简单的 UI 元素使用函数式组件。
- 设计组件时考虑可重用性和可测试性。
- 考虑使用插槽进行灵活的组件组合。
- **代码分割：**
- 利用动态导入进行基于路由的代码分割。
- 使用 `import()` 将大组件分割成更小的块。
- 使用 Webpack Bundle Analyzer 等工具分析包大小。
## 2. 常见模式和反模式：
- **设计模式：**
- **组合式 API：** 使用组合式 API 来组织组件逻辑。
- **Store 模式 (Pinia)：** 使用 Pinia 实现集中式状态管理系统。
- **中间件模式：** 使用中间件进行身份验证、授权和数据验证。
- **插件模式：** 为全局功能和第三方库集成创建插件。
- **推荐方法：**
- **API 通信：** 在组件内使用 `useFetch` 或 `useAsyncData` 组合式函数进行 API 调用。
- **表单处理：** 利用 Vue 的内置表单处理功能与 `v-model` 和像 VeeValidate 这样的验证库。
- **身份验证：** 使用 `@nuxt/auth` 库或自定义解决方案实现安全的身份验证流程。
- **授权：** 使用中间件和 Pinia stores 实现基于角色的访问控制 (RBAC)。
- **反模式：**
- **直接修改 props：** 避免从子组件直接修改父组件数据。请使用 `emit` 代替。
- **过度使用全局状态：** 将全局状态的使用限制在必要的应用程序数据上。对本地数据考虑使用组件级状态。
- **忽略错误处理：** 始终处理 API 调用和其他异步操作中的潜在错误。
- **编写过于复杂的组件：** 将大组件分解为更小、更易管理的部分。
- **状态管理最佳实践：**
- **单一数据源：** 在 Pinia stores 中为应用程序状态维护单一、一致的数据源。
- **不可变性：** 将状态视为不可变的。使用函数来更新 store 而不是直接操作数据。
- **清晰的命名约定：** 为 store 模块、actions 和 mutations 使用描述性名称。
- **模块化：** 根据功能或特性将 stores 分成模块。
- **错误处理模式：**
- **集中式错误处理：** 实现全局错误处理器来捕获未处理的异常。
- **错误边界：** 使用错误边界来隔离组件故障并防止级联错误。
- **用户友好的错误消息：** 为用户提供清晰和有用的错误消息。
## 3. 性能考虑：
- **优化技术：**
- **懒加载：** 为图片、组件和路由实现懒加载。
- **代码分割：** 将应用程序分割成更小的块以获得更快的初始加载时间。
- **Tree Shaking：** 在构建过程中删除未使用的代码。
- **缓存：** 缓存 API 响应和静态资源以减少服务器负载。
- **图片优化：** 使用 `nuxt/image` 等工具优化图片。使用适当的图片格式（WebP）。将图片大小调整为适当大小。考虑使用 CDN 进行图片交付。
- **内存管理：**
- **避免内存泄漏：** 在组件卸载时清理事件监听器和定时器。
- **使用弱引用：** 在可能的情况下对 DOM 元素使用弱引用。
- **最小化对象创建：** 避免创建不必要的对象和数组。
- **渲染优化：**
- **虚拟化：** 对大列表使用虚拟化以提高渲染性能。
- **记忆化：** 记忆化昂贵的计算以避免冗余计算。有效使用 `computed` 属性以避免不必要的重新渲染。
- **防抖和节流：** 对事件处理器使用防抖和节流以减少函数调用次数。
- **包大小优化：**
- **分析包大小：** 使用 Webpack Bundle Analyzer 识别大依赖项。
- **删除未使用的依赖项：** 删除未使用的依赖项以减少包大小。
- **使用更小的替代方案：** 考虑使用更小的替代方案来替代大型库。
- **优化依赖项：** 检查依赖项并确保您使用的是最高效的版本。
- **懒加载策略：**
- **基于路由的懒加载：** 仅在访问相应路由时加载组件。
- **基于组件的懒加载：** 仅在组件在视口中可见时加载组件。
## 4. 安全最佳实践：
- **常见漏洞：**
- **跨站脚本攻击 (XSS)：** 通过正确清理用户输入和使用 Vue 的内置 HTML 转义来防止 XSS 攻击。
- **跨站请求伪造 (CSRF)：** 通过实现 CSRF 令牌来防止 CSRF 攻击。
- **SQL 注入：** 避免原始 SQL 查询。使用 ORM（对象关系映射器）来防止 SQL 注入。
- **身份验证和授权缺陷：** 实现安全的身份验证和授权机制。
- **不安全的直接对象引用 (IDOR)：** 实现适当的访问控制以防止对资源的未授权访问。
- **输入验证：**
- **服务端验证：** 始终在服务端验证用户输入。
- **客户端验证：** 提供客户端验证以获得更好的用户体验（但不要依赖它作为验证的唯一来源）。
- **清理输入：** 清理用户输入以删除潜在的有害字符。
- **身份验证和授权模式：**
- **JWT（JSON Web Tokens）：** 使用 JWT 进行身份验证和授权。
- **OAuth 2.0：** 为第三方身份验证实现 OAuth 2.0。
- **基于角色的访问控制 (RBAC)：** 实现 RBAC 来根据用户角色控制对资源的访问。
- **数据保护策略：**
- **加密：** 对静态和传输中的敏感数据进行加密。
- **散列：** 使用强散列算法对密码和其他敏感数据进行散列。
- **数据屏蔽：** 在日志和其他非生产环境中屏蔽敏感数据。
- **安全的 API 通信：**
- **HTTPS：** 始终使用 HTTPS 进行 API 通信。
- **API 速率限制：** 实现 API 速率限制以防止滥用。
- **身份验证和授权：** 对所有 API 端点要求身份验证和授权。
## 5. 测试方法：
- **单元测试：**
- **测试单个组件：** 孤立地测试单个组件。
- **模拟依赖项：** 模拟外部依赖项以在测试期间隔离组件。
- **验证组件行为：** 验证组件正确渲染并按预期行为。
- **集成测试：**
- **测试组件交互：** 测试组件之间的交互。
- **测试数据流：** 测试组件和 stores 之间的数据流。
- **测试 API 集成：** 测试与外部 API 的集成。
- **端到端测试：**
- **模拟用户交互：** 模拟用户交互以测试应用程序的功能。
- **测试整个应用程序流程：** 从头到尾测试整个应用程序流程。
- **使用浏览器自动化工具：** 使用 Cypress 或 Playwright 等浏览器自动化工具。
- **测试组织：**
- **按功能组织测试：** 按功能或特性组织测试。
- **使用描述性测试名称：** 使用描述性测试名称来清楚地说明每个测试正在测试什么。
- **保持测试隔离：** 保持测试彼此隔离以避免干扰。
- **模拟和存根：**
- **使用模拟对象：** 使用模拟对象在测试期间替换外部依赖项。
- **使用存根：** 使用存根用简化版本替换复杂函数。
- **避免过度模拟：** 避免模拟太多代码，因为这会使测试效果降低。
## 6. 常见陷阱和注意事项：
- **常见错误：**
- **错误的 `this` 上下文：** 注意 Vue 组件中的 `this` 上下文，使用箭头函数或 `bind` 来维护正确的上下文。
- **异步数据处理：** 使用 `async/await` 或 Promises 正确处理异步数据加载。
- **忘记取消订阅：** 在组件卸载时取消订阅事件监听器和定时器以防止内存泄漏。
- **过度使用 `forceUpdate`：** 除非绝对必要，否则避免使用 `forceUpdate`，因为它会对性能产生负面影响。
- **边缘情况：**
- **服务端渲染 (SSR)：** 了解客户端和服务端渲染之间的差异。
- **浏览器兼容性：** 在不同浏览器中测试应用程序以确保兼容性。
- **可访问性：** 在设计和开发应用程序时考虑可访问性。
- **版本特定问题：**
- **Nuxt 2 vs Nuxt 3：** 了解 Nuxt 2 和 Nuxt 3 之间的差异。
- **Vue 2 vs Vue 3：** 了解 Vue 2 和 Vue 3 之间的差异。
- **依赖项更新：** 仔细检查依赖项更新是否存在潜在的破坏性更改。
- **兼容性问题：**
- **浏览器支持：** 确保与目标浏览器兼容。
- **设备兼容性：** 在不同设备上测试应用程序。
- **操作系统兼容性：** 确保与目标操作系统兼容。
- **调试策略：**
- **使用浏览器开发者工具：** 使用浏览器开发者工具检查应用程序的状态和网络活动。
- **使用 Vue Devtools：** 使用 Vue Devtools 检查 Vue 组件和数据。
- **使用日志记录：** 使用日志记录来跟踪应用程序的行为。
## 7. 工具和环境：
- **推荐的开发工具：**
- **VS Code：** Visual Studio Code 是一个流行的代码编辑器，具有出色的 Vue.js 支持。
- **Vue Devtools：** Vue Devtools 是一个浏览器扩展，为 Vue.js 应用程序提供调试工具。
- **ESLint：** ESLint 是一个强制执行编码标准的代码检查器。
- **Prettier：** Prettier 是一个自动格式化代码的代码格式化器。
- **构建配置：**
- **`nuxt.config.js` 或 `nuxt.config.ts`：** 在 `nuxt.config.js` 或 `nuxt.config.ts` 中配置应用程序的构建设置。
- **Webpack：** Nuxt 使用 Webpack 来打包应用程序。
- **Vite：** Nuxt 3 默认使用 Vite 来打包应用程序，提供更快的构建和开发时间。
- **代码检查和格式化：**
- **ESLint：** 使用 ESLint 强制执行编码标准。
- **Prettier：** 使用 Prettier 自动格式化代码。
- **Husky：** 使用 Husky 在提交前运行代码检查器和格式化器。
- **部署最佳实践：**
- **服务端渲染 (SSR)：** 将应用程序部署到支持 SSR 的服务器。
- **静态站点生成 (SSG)：** 为内容丰富的应用程序生成静态站点。
- **CDN：** 使用 CDN 交付静态资源。
- **CI/CD 集成：**
- **持续集成 (CI)：** 使用 Jenkins、GitLab CI 或 GitHub Actions 等 CI 工具自动化构建和测试过程。
- **持续部署 (CD)：** 使用 CD 工具自动化部署过程。
通过遵循这些最佳实践，您可以构建强健、可维护且可扩展的 Nuxt.js 应用程序。

190
content/blog/1.技术栈/13.Python 代码规范.md Normal file
View File

@@ -0,0 +1,190 @@
---
title: Python 代码规范
description: 这是一份提供给AI大模型的Python代码规范与编程标准，可以有效提高Cursor等大模型对Python项目的编写能力。
date: 2025-07-12
img: https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250624130616733.png
navigation:
icon: simple-icons:python
---
# 概述
这是一份提供给AI大模型的Python代码规范与编程标准，可以有效提高Cursor等大模型对Python项目的编写能力。
---
description: Python开发综合指南，涵盖代码组织、性能、安全性、测试等内容。这些规则旨在促进可维护、高效且安全的Python代码库。
globs: *.py
---
# Python最佳实践与编码规范
本文档概述了Python开发的综合最佳实践和编码标准，旨在促进编写干净、高效、可维护和安全的代码。
## 1. 代码组织与结构
### 1.1 目录结构最佳实践
* **扁平结构优于嵌套（但不绝对）。** 从简单结构开始，按需重构
* **包与模块：** 使用包（包含`__init__.py`的目录）对模块进行逻辑分组
* **src布局：** 考虑使用`src`目录分离应用代码和项目级文件（setup.py、requirements.txt等），避免导入冲突并明确项目边界
* **典型项目结构：**
project_name/
├── src/
│ ├── package_name/
│ │ ├── __init__.py
│ │ ├── module1.py
│ │ ├── module2.py
│ ├── main.py # 入口文件
├── tests/
│ ├── __init__.py
│ ├── test_module1.py
│ ├── test_module2.py
├── docs/
│ ├── conf.py
│ ├── index.rst
├── .gitignore
├── pyproject.toml 或 setup.py
├── README.md
├── requirements.txt 或 requirements-dev.txt
### 1.2 文件命名规范
* **模块：** 小写字母，使用下划线增强可读性（如`my_module.py`）
* **包：** 全小写（如`my_package`），非必要不使用下划线
* **测试文件：** 以`test_`开头（如`test_my_module.py`）
### 1.3 模块组织最佳实践
* **单一职责原则：** 每个模块应有明确定义的用途
* **导入规范：**
* 顺序：标准库→第三方库→本地模块
* 优先使用绝对导入（如`from my_package.module1 import function1`）
* 在复杂包结构中需明确相对导入时使用显式相对导入（`from . import sibling_module`）
* **常量：** 使用全大写定义模块级常量（如`MAX_ITERATIONS = 100`）
* **双下划线名称：** `__all__`、`__version__`等应放在模块文档字符串之后、所有导入之前（`from __future__`除外）。使用`__all__`显式声明公共API
### 1.4 组件架构建议
* **分层架构：** 适用于大型应用，将关注点分离为表现层、业务逻辑层和数据访问层
* **微服务：** 超大型系统可拆分为小型独立服务
* **六边形/整洁架构：** 强调业务逻辑与数据库/框架等外部依赖的解耦
* **依赖注入：** 提高可测试性并降低耦合度
### 1.5 代码分割策略
* **按功能拆分：** 基于不同功能划分模块（如用户管理、数据处理）
* **按层级拆分：** 分离表现层、业务逻辑层和数据访问代码
* **懒加载：** 使用`importlib.import_module()`实现按需加载，优化启动时间
* **条件导入：** 根据特定条件导入模块
## 2. 常见模式与反模式
### 2.1 设计模式
* **单例模式：** 限制类只能实例化一个对象
* **工厂模式：** 创建对象时无需指定具体类
* **观察者模式：** 建立对象间一对多依赖关系
* **策略模式：** 定义算法族并使其可互换
* **装饰器模式：** 动态扩展对象功能
* **上下文管理器：** 确保资源正确清理（如自动关闭文件）
### 2.2 常见任务的推荐方案
* **数据验证：** 使用`pydantic`或`marshmallow`等库
* **配置管理：** 使用`python-decouple`、`dynaconf`或标准库的`configparser`
* **日志记录：** 使用`logging`模块实现结构化日志
* **命令行接口：** 使用`argparse`、`click`或`typer`
* **异步编程：** 使用`asyncio`处理I/O密集型任务
### 2.3 反模式与代码异味
* **上帝类：** 承担过多职责的类，应拆分为专注单一功能的小类
* **霰弹式变更：** 需在多处做小修改，表明内聚性不足
* **面条代码：** 结构混乱难以追踪，应重构为定义明确的函数/类
* **重复代码：** 提取公共代码为可复用函数/类（遵循DRY原则）
* **魔法数值/字符串：** 使用命名常量替代硬编码值
* **过早优化：** 避免在没有性能瓶颈分析前提下的优化
### 2.4 状态管理最佳实践
* **无状态函数：** 尽可能使用无状态函数
* **不可变数据：** 使用不可变数据结构防止意外修改
* **显式状态：** 使用类或数据结构明确管理状态，避免全局变量
* **上下文变量：** Python 3.7+可使用`contextvars`管理异步应用中的请求级状态
### 2.5 错误处理模式
* **捕获特定异常：** 避免笼统捕获`Exception`或`BaseException`
* **资源清理：** 使用`finally`确保清理代码必执行
* **异常日志：** 记录完整堆栈信息
* **异常消息：** 抛出包含明确错误信息的异常
* **避免异常控制流：** 异常应用于处理意外情况而非常规流程
## 3. 性能优化
### 3.1 优化技术
* **性能分析：** 使用`cProfile`定位瓶颈
* **高效数据结构：** 根据场景选择（如`set`用于成员测试、`dict`用于查找）
* **列表推导式与生成器：** 编写简洁高效的代码
* **NumPy向量化：** 对数值计算使用向量化操作
* **即时编译：** 性能关键代码考虑使用Numba等JIT编译器
* **字符串拼接：** 使用`''.join(iterable)`高效拼接字符串
### 3.2 内存管理
* **内存分析：** 使用`memory_profiler`定位内存泄漏
* **`__slots__`：** 减少类实例的内存占用
* **生成器：** 处理大数据集时避免全部加载到内存
## 4. 安全性最佳实践
### 4.1 常见漏洞防范
* **SQL注入：** 使用参数化查询或ORM
* **XSS攻击：** 对用户输入消毒并转义输出
* **CSRF防护：** 使用CSRF令牌
* **依赖漏洞：** 定期审计和更新依赖项
* **硬编码密钥：** 禁止在代码中硬编码密码/API密钥，使用环境变量管理
### 4.2 API安全通信
* **强制HTTPS：** 所有API通信必须加密
* **速率限制：** 防止接口滥用
* **输入验证：** 处理前验证所有API请求
## 5. 测试策略
### 5.1 单元测试要点
* **测试粒度：** 隔离测试单个函数/类/模块
* **边界条件：** 特别测试边界情况和异常场景
* **测试覆盖率：** 追求高覆盖率但避免教条化
### 5.2 集成测试建议
* **聚焦关键流程：** 关注核心用户场景
* **模拟外部服务：** 使用mock替代真实外部依赖
## 6. 常见陷阱
### 6.1 高频错误
* **可变默认参数：** 函数定义中避免使用可变对象作为默认值
* **变量作用域：** 注意嵌套函数中的变量作用域
* **忽略异常：** 禁止直接忽略未处理的异常
* **虚拟环境：** 必须使用虚拟环境管理项目依赖
## 7. 工具与环境
### 7.1 推荐工具链
* **IDE：** PyCharm、VS Code（搭配Python插件）
* **包管理：** `pip`、`poetry`
* **格式化：** `black`、`autopep8`
* **静态检查：** `mypy`、`pylint`
### 7.2 CI/CD集成
* **自动化测试：** 每次提交自动运行测试套件
* **代码质量门禁：** 集成静态分析工具到流水线
遵循这些规范和最佳实践，开发者能够构建出更健壮、可维护且安全的Python应用。

190
content/blog/1.技术栈/14.Coolify.md Normal file
View File

@@ -0,0 +1,190 @@
---
title: Coolify
description: Coolify是什么？
date: 2025-07-14
img: https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250628122847084.png
navigation:
icon: simple-icons:chai
---
# 概述
这是一份提供给AI大模型的Python代码规范与编程标准，可以有效提高Cursor等大模型对Python项目的编写能力。
---
description: Python开发综合指南，涵盖代码组织、性能、安全性、测试等内容。这些规则旨在促进可维护、高效且安全的Python代码库。
globs: *.py
---
# Python最佳实践与编码规范
本文档概述了Python开发的综合最佳实践和编码标准，旨在促进编写干净、高效、可维护和安全的代码。
## 1. 代码组织与结构
### 1.1 目录结构最佳实践
* **扁平结构优于嵌套（但不绝对）。** 从简单结构开始，按需重构
* **包与模块：** 使用包（包含`__init__.py`的目录）对模块进行逻辑分组
* **src布局：** 考虑使用`src`目录分离应用代码和项目级文件（setup.py、requirements.txt等），避免导入冲突并明确项目边界
* **典型项目结构：**
project_name/
├── src/
│ ├── package_name/
│ │ ├── __init__.py
│ │ ├── module1.py
│ │ ├── module2.py
│ ├── main.py # 入口文件
├── tests/
│ ├── __init__.py
│ ├── test_module1.py
│ ├── test_module2.py
├── docs/
│ ├── conf.py
│ ├── index.rst
├── .gitignore
├── pyproject.toml 或 setup.py
├── README.md
├── requirements.txt 或 requirements-dev.txt
### 1.2 文件命名规范
* **模块：** 小写字母，使用下划线增强可读性（如`my_module.py`）
* **包：** 全小写（如`my_package`），非必要不使用下划线
* **测试文件：** 以`test_`开头（如`test_my_module.py`）
### 1.3 模块组织最佳实践
* **单一职责原则：** 每个模块应有明确定义的用途
* **导入规范：**
* 顺序：标准库→第三方库→本地模块
* 优先使用绝对导入（如`from my_package.module1 import function1`）
* 在复杂包结构中需明确相对导入时使用显式相对导入（`from . import sibling_module`）
* **常量：** 使用全大写定义模块级常量（如`MAX_ITERATIONS = 100`）
* **双下划线名称：** `__all__`、`__version__`等应放在模块文档字符串之后、所有导入之前（`from __future__`除外）。使用`__all__`显式声明公共API
### 1.4 组件架构建议
* **分层架构：** 适用于大型应用，将关注点分离为表现层、业务逻辑层和数据访问层
* **微服务：** 超大型系统可拆分为小型独立服务
* **六边形/整洁架构：** 强调业务逻辑与数据库/框架等外部依赖的解耦
* **依赖注入：** 提高可测试性并降低耦合度
### 1.5 代码分割策略
* **按功能拆分：** 基于不同功能划分模块（如用户管理、数据处理）
* **按层级拆分：** 分离表现层、业务逻辑层和数据访问代码
* **懒加载：** 使用`importlib.import_module()`实现按需加载，优化启动时间
* **条件导入：** 根据特定条件导入模块
## 2. 常见模式与反模式
### 2.1 设计模式
* **单例模式：** 限制类只能实例化一个对象
* **工厂模式：** 创建对象时无需指定具体类
* **观察者模式：** 建立对象间一对多依赖关系
* **策略模式：** 定义算法族并使其可互换
* **装饰器模式：** 动态扩展对象功能
* **上下文管理器：** 确保资源正确清理（如自动关闭文件）
### 2.2 常见任务的推荐方案
* **数据验证：** 使用`pydantic`或`marshmallow`等库
* **配置管理：** 使用`python-decouple`、`dynaconf`或标准库的`configparser`
* **日志记录：** 使用`logging`模块实现结构化日志
* **命令行接口：** 使用`argparse`、`click`或`typer`
* **异步编程：** 使用`asyncio`处理I/O密集型任务
### 2.3 反模式与代码异味
* **上帝类：** 承担过多职责的类，应拆分为专注单一功能的小类
* **霰弹式变更：** 需在多处做小修改，表明内聚性不足
* **面条代码：** 结构混乱难以追踪，应重构为定义明确的函数/类
* **重复代码：** 提取公共代码为可复用函数/类（遵循DRY原则）
* **魔法数值/字符串：** 使用命名常量替代硬编码值
* **过早优化：** 避免在没有性能瓶颈分析前提下的优化
### 2.4 状态管理最佳实践
* **无状态函数：** 尽可能使用无状态函数
* **不可变数据：** 使用不可变数据结构防止意外修改
* **显式状态：** 使用类或数据结构明确管理状态，避免全局变量
* **上下文变量：** Python 3.7+可使用`contextvars`管理异步应用中的请求级状态
### 2.5 错误处理模式
* **捕获特定异常：** 避免笼统捕获`Exception`或`BaseException`
* **资源清理：** 使用`finally`确保清理代码必执行
* **异常日志：** 记录完整堆栈信息
* **异常消息：** 抛出包含明确错误信息的异常
* **避免异常控制流：** 异常应用于处理意外情况而非常规流程
## 3. 性能优化
### 3.1 优化技术
* **性能分析：** 使用`cProfile`定位瓶颈
* **高效数据结构：** 根据场景选择（如`set`用于成员测试、`dict`用于查找）
* **列表推导式与生成器：** 编写简洁高效的代码
* **NumPy向量化：** 对数值计算使用向量化操作
* **即时编译：** 性能关键代码考虑使用Numba等JIT编译器
* **字符串拼接：** 使用`''.join(iterable)`高效拼接字符串
### 3.2 内存管理
* **内存分析：** 使用`memory_profiler`定位内存泄漏
* **`__slots__`：** 减少类实例的内存占用
* **生成器：** 处理大数据集时避免全部加载到内存
## 4. 安全性最佳实践
### 4.1 常见漏洞防范
* **SQL注入：** 使用参数化查询或ORM
* **XSS攻击：** 对用户输入消毒并转义输出
* **CSRF防护：** 使用CSRF令牌
* **依赖漏洞：** 定期审计和更新依赖项
* **硬编码密钥：** 禁止在代码中硬编码密码/API密钥，使用环境变量管理
### 4.2 API安全通信
* **强制HTTPS：** 所有API通信必须加密
* **速率限制：** 防止接口滥用
* **输入验证：** 处理前验证所有API请求
## 5. 测试策略
### 5.1 单元测试要点
* **测试粒度：** 隔离测试单个函数/类/模块
* **边界条件：** 特别测试边界情况和异常场景
* **测试覆盖率：** 追求高覆盖率但避免教条化
### 5.2 集成测试建议
* **聚焦关键流程：** 关注核心用户场景
* **模拟外部服务：** 使用mock替代真实外部依赖
## 6. 常见陷阱
### 6.1 高频错误
* **可变默认参数：** 函数定义中避免使用可变对象作为默认值
* **变量作用域：** 注意嵌套函数中的变量作用域
* **忽略异常：** 禁止直接忽略未处理的异常
* **虚拟环境：** 必须使用虚拟环境管理项目依赖
## 7. 工具与环境
### 7.1 推荐工具链
* **IDE：** PyCharm、VS Code（搭配Python插件）
* **包管理：** `pip`、`poetry`
* **格式化：** `black`、`autopep8`
* **静态检查：** `mypy`、`pylint`
### 7.2 CI/CD集成
* **自动化测试：** 每次提交自动运行测试套件
* **代码质量门禁：** 集成静态分析工具到流水线
遵循这些规范和最佳实践，开发者能够构建出更健壮、可维护且安全的Python应用。

79
content/blog/1.技术栈/15.Supabase 阿里云短信.md Normal file
View File

@@ -0,0 +1,79 @@
---
title: Supabase 阿里云短信
description: Supabase - 添加国内阿里云短信、微信扫码认证登录
date: 2025-07-15
img: https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250701003525007.png
navigation:
icon: simple-icons:alibabacloud
---
###### 给 Supabase 添加一项新的功能
Supabase 自身的鉴权组件是社区开源项目 GoTrue ，由 GO 语言开发
Supabase 提供的短信验证都是国外的厂商，并不适应国内环境
##### 实现
单独把 Gotrue 仓库克隆下来，添加修改需要的功能
测试好后打包为 Docker，推到私有库
修改 Supabase 的 Docker Compose 文件，image 改为私有库镜像并拉取！
##### 并没有提交 PR，直接放在仓库，具体使用方法看仓库说明
###### [Github 仓库地址](https://github.com/estel-li/supabase_auth_aliyun_wechat)
---
### 🚀 新增功能
### 1. 阿里云短信服务 (Aliyun SMS)
- ✅ 完整的阿里云短信 API 集成
- ✅ 支持 HMAC-SHA1 签名验证
- ✅ 支持中文短信签名
- ✅ 支持 OTP 验证码发送
- ✅ 完整的错误处理和响应解析
### 2. 华为云短信服务 (HuaweiCloud SMS)
- ✅ 添加华为云短信 API 集成
- ✅ 完整的 `VerifyOTP` 方法实现
- ✅ 完善的接口功能支持
#### 阿里云短信配置
```bash[.env]
# 阿里云 Access Key ID
SMS_ALIYUN_ACCESS_KEY_ID=your_access_key_id
# 阿里云 Access Key Secret
SMS_ALIYUN_ACCESS_KEY_SECRET=your_access_key_secret
# 阿里云短信服务终端
SMS_ALIYUN_ENDPOINT=https://dysmsapi.aliyuncs.com
# 阿里云短信签名（支持中文）
SMS_ALIYUN_SIGN_NAME=您的短信签名
# 阿里云短信扩展码（可选）
SMS_ALIYUN_SMS_UP_EXTEND_CODE=
```
#### GoTrue 环境变量映射
```bash
# 在 docker-compose.yml 中映射到 GoTrue 容器
GOTRUE_SMS_ALIYUN_ACCESS_KEY_ID=${SMS_ALIYUN_ACCESS_KEY_ID}
GOTRUE_SMS_ALIYUN_ACCESS_KEY_SECRET=${SMS_ALIYUN_ACCESS_KEY_SECRET}
GOTRUE_SMS_ALIYUN_ENDPOINT=${SMS_ALIYUN_ENDPOINT}
GOTRUE_SMS_ALIYUN_SIGN_NAME=${SMS_ALIYUN_SIGN_NAME}
GOTRUE_SMS_ALIYUN_SMS_UP_EXTEND_CODE=${SMS_ALIYUN_SMS_UP_EXTEND_CODE}
```

132
content/blog/1.技术栈/16.Nuxt UI Pro.md Normal file
View File

@@ -0,0 +1,132 @@
---
title: Nuxt UI Pro
description: Nuxt 被收购后，预计在9月发布 Nuxt UI Pro v4,并且全免费
date: 2025-07-25
img: https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250723114628628.png
navigation:
icon: simple-icons:nuxtdotjs
---
Nuxt 被收购后，预计在9月发布 Nuxt UI Pro v4,并且全免费。
于是把最近在做的项目 UI 组件换成了 Nuxt UI Pro。
不过9月才免费，现在就忍不住上了组件，总不至于去缴几百美元的费用吧。
![image.png](https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250723110524418.png)
于是先绕过一些验证过程，体验一下“学习版”。
做一个 shell 脚本，在项目根目录下执行即可完成跳过。pnpm i 安装完或者更新完依赖就执行一次即可。
```bash [.shell]
# 绕过 UI Pro 的 License 验证
set -euo pipefail
# 1. 禁用 module.mjs 的调用
MODULE="node_modules/@nuxt/ui-pro/dist/module.mjs"
if [[ -f $MODULE ]]; then
sed -i.bak '/await validateLicense({.*rootDir })/s/^/\/\//; /^await validateLicense({.*rootDir })/s/^/\/\//' "$MODULE"
rm -f "$MODULE.bak"
echo "✅ module.mjs 已屏蔽"
fi
# 2. 直接“替换函数” fake 200
SHARED="node_modules/@nuxt/ui-pro/dist/shared"
JS=$(find "$SHARED" -maxdepth 1 -name 'ui-pro.*.mjs' | head -n1)
[[ -z $JS || ! -f $JS ]] && { echo "⚠️ ui-pro.*.mjs 未找到"; exit 0; }
cat <<'EOF' > tmp_func.mjs
async function validateLicense(opts) {
/* --- patched --- */
return { status: 200 }
}
EOF
sed -i.bak '/^async function validateLicense[^(]*(/,/^\}$/c\
async function validateLicense(opts) {\
/* --- patched --- */\
return { status: 200 }\
}\
' "$JS"
rm -f "$JS.bak" tmp_func.mjs
echo "✅ $JS 已 mock 完成"
echo "🎉 License ⛔ Done!"
```
### 以上脚本是自动化完成以下操作：
修改 `node_modules\@nuxt\ui-pro\dist\module.mjs`
```js
nuxt.hook("build:before", async () => {
// 注释掉这行
// await validateLicense({ key, theme: theme$1, dir: nuxt.options.rootDir });
});
```
修改 `node_modules/@nuxt/ui-pro/dist/shared/ui-pro.CsgJ05mi.mjs`
此目录下 ui-pro.xxx.mjs 名称是随机生成
```js
async function validateLicense(opts) {
//注释下方代码
// if (!opts.key) {
// throw _createError(`Missing \`${opts.theme.env}\` license key.
// Purchase Nuxt UI Pro at \`${opts.theme.link}\` to build your app in production.`);
// }
// const gitInfo = opts.key !== "oss" ? void 0 : await _getLocalGitInfo(opts.dir) || _getGitEnv();
// const projectName = gitInfo ? `${gitInfo.owner || ""}/${gitInfo.name || ""}` : await _getPkgName(opts.dir);
// try {
// await ofetch("https://api.nuxtlabs.com/ui-pro/verify", {
// headers: {
// "Authorization": `key ${opts.key}`,
// "x-nuxt-project": projectName
// },
// params: gitInfo ? {
// gitRepo: gitInfo.name,
// gitOrg: gitInfo.owner,
// gitUrl: gitInfo.url
// } : {}
// });
// } catch (error) {
// const statusType = Math.round(error.status / 100);
// if (statusType === 4) {
// throw _createError(`Invalid \`${opts.theme.env}\` license key.
// Purchase Nuxt UI Pro at \`${opts.theme.link}\` to build your app in production.`);
// }
// throw _createError("Cannot validate Nuxt UI Pro License: " + error);
// }
/手动添加返回 200 状态值
const response = {
status: 200,
};
return response;
}
```

56
content/blog/1.技术栈/17.树莓派安装 Kali Linux.md Normal file
View File

@@ -0,0 +1,56 @@
---
title: 树莓派安装 Kali Linux
description: 如何在树莓派设备上安装 Kali Linux 系统，包括镜像下载、烧录、启动及基础配置等步骤，适合初学者快速上手。
date: 2025-08-06
img: https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250805232800775.png
navigation:
icon: simple-icons:raspberrypi
---
## 为什么要给树莓派安装 Kali？
- **迷你渗透实验室**：树莓派 4B/5 拥有 4–8 GB RAM，运行 Kali 足够跑 Metasploit、Burp Suite、Aircrack-ng。
- **低功耗随身“盒子”**：U 盘大小，插充电宝就能跑 8 h，现场测试不易被发现。
- **多元化玩法**：可以当 AP（Fake-Wi-Fi）、HID 攻击机（P4wnP1）、其他载荷平台。
树莓派4B 一个,此物曾经可以**理财** ,价格一度涨到离谱.
平价的时候买了一个,玩了多年,换过好几个3D打印的外壳,图中这个最是满意.
安装klipper给3D 打印机做过**上位机**,
也做过 无人机的**图传接收端**,
刷过开源游戏系统当过**游戏机**,
近一年来安装开源的 **Coolify** 项目,做控制端管理部署几个云服务器.
绝对是物尽其用了.
## 安装
安装方法网上一大把,也可以直接问 AI.
主要是一些配置:
- 其实也是所有 Linux 配置的基本操作
- Kali 基于 Debian 系 ,所有配置差不多.
备份源
```
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
```
使用喜欢的编译器编辑
```
sudo nano /etc/apt/sources.list
```
注释官方源,添加国内镜像源
```
deb http://mirrors.tuna.tsinghua.edu.cn/kali kali-rolling main contrib non-free non-free-firmware
```
然后更新源
```
sudo apt update && sudo apt upgrade -y
```
![](https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250805222957495.png)
![image.png](https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250805223025332.png)
![image.png](https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250805213607111.png)
![image.png](https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250805232800775.png)
这样, Kali 就安好了,很**可拷**,**很刑**的.

56
content/blog/1.技术栈/18.系统安全综合评估报告.md Normal file
View File

@@ -0,0 +1,56 @@
---
title: 系统安全综合评估报告
description: Kali 生成的系统安全综合评估报告
date: 2025-08-07
img: https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250806104913997.png
navigation:
icon: simple-icons:kalilinux
---
## 为什么要给树莓派安装 Kali？
- **迷你渗透实验室**：树莓派 4B/5 拥有 4–8 GB RAM，运行 Kali 足够跑 Metasploit、Burp Suite、Aircrack-ng。
- **低功耗随身“盒子”**：U 盘大小，插充电宝就能跑 8 h，现场测试不易被发现。
- **多元化玩法**：可以当 AP（Fake-Wi-Fi）、HID 攻击机（P4wnP1）、其他载荷平台。
树莓派4B 一个,此物曾经可以**理财** ,价格一度涨到离谱.
平价的时候买了一个,玩了多年,换过好几个3D打印的外壳,图中这个最是满意.
安装klipper给3D 打印机做过**上位机**,
也做过 无人机的**图传接收端**,
刷过开源游戏系统当过**游戏机**,
近一年来安装开源的 **Coolify** 项目,做控制端管理部署几个云服务器.
绝对是物尽其用了.
## 安装
安装方法网上一大把,也可以直接问 AI.
主要是一些配置:
- 其实也是所有 Linux 配置的基本操作
- Kali 基于 Debian 系 ,所有配置差不多.
备份源
```
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
```
使用喜欢的编译器编辑
```
sudo nano /etc/apt/sources.list
```
注释官方源,添加国内镜像源
```
deb http://mirrors.tuna.tsinghua.edu.cn/kali kali-rolling main contrib non-free non-free-firmware
```
然后更新源
```
sudo apt update && sudo apt upgrade -y
```
![](https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250805222957495.png)
![image.png](https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250805223025332.png)
![image.png](https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250805213607111.png)
![image.png](https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250805232800775.png)
这样, Kali 就安好了,很**可拷**,**很刑**的.

562
content/blog/1.技术栈/19.系统安全扫描工具命令集合.md Normal file
View File

@@ -0,0 +1,562 @@
---
title: 系统安全扫描工具命令集合
description: Kali 所使用的系统安全扫描工具命令集合
date: 2025-08-07
img: https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250806105029318.png
navigation:
icon: simple-icons:openstreetmap
---
## 完整命令参数指南 - 针对192.168.1.2
---
## 🔍 网络发现与端口扫描
### 基础端口扫描
```bash
# TCP端口快速扫描
nmap -sS -sV -p 1-1000 192.168.1.2
# 全端口TCP扫描
nmap -sS -sV -p- --script vuln 192.168.1.2
# UDP端口发现
nmap -sU -sV --top-ports 1000 192.168.1.2
# 综合扫描 (TCP+UDP+OS检测+脚本漏洞扫描)
nmap -sS -sU -sV -O -A --script discovery,default,vuln -p- 192.168.1.2 --host-timeout 300
```
### 服务版本检测
```bash
# 详细服务版本信息
nmap -sV -A 192.168.1.2 -p 22,80,111,139,443,445
# OS系统指纹识别
sudo nmap -O 192.168.1.2
```
---
## 🌐 Web应用安全测试
### 目录与文件发现
```bash
# 标准目录爆破 (默认字典)
dirb http://192.168.1.2 -o /tmp/dirb_scan.txt
# 使用GoBuster (更快字典)
timeout 30 gobuster dir -u http://192.168.1.2 \
-w /usr/share/wordlists/dirb/common.txt \
-q -o /tmp/gobuster.txt
# HTTPS目录扫描
gobuster dir -u https://192.168.1.2 \
-w /usr/share/wordlists/dirb/common.txt \
-k (-k参数忽略SSL证书错误)
```
### Web漏洞扫描
```bash
# Nikto综合漏洞扫描
nikto -h 192.168.1.2 -p 80,443 -output /tmp/nikto_http.txt
# SSL/TLS配置测试
sslyze 192.168.1.2:443 \
--certinfo \
--heartbleed \
--tlsv1 --tlsv1_1 --tlsv1_2 --tlsv1_3 \
> /tmp/ssl_analysis.txt
# 技术指纹识别
whatweb -v 192.168.1.2
```
### HTTP头部分析
```bash
# 获取HTTP头部
curl -s -I http://192.168.1.2
curl -s -I -k https://192.168.1.2
# 获取完整响应
curl -s -L http://192.168.1.2 | head -50
curl -s -L -k https://192.168.1.2 | head -50
```
---
## 🔐 SSH安全配置检查
### SSH信息收集
```bash
# SSH版本扫描
nmap -sC -p22 192.168.1.2 -oN /tmp/ssh_nmap.txt
# SSH连接测试
timeout 10 nc -zv 192.168.1.2 22
# SSH版本识别
curl -s telnet://192.168.1.2:22 | head -3
# 基础认证测试 (需要SSH-audit，如未安装)
# ssh-audit 192.168.1.2
```
---
## 📁 文件共享服务分析
### SMB/Samba评估
```bash
# 匿名共享发现
smbclient -L //192.168.1.2 -N
# 详细Samba信息收集
enum4linux -a 192.168.1.2 > /tmp/smb_enum.txt
# RPC服务探测
rpcclient -U "" -N -c srvinfo 192.168.1.2
# NBT协议信息
timeout 15 nbtscan -r 192.168.1.2 > /tmp/nbtscan_result.txt
```
### 共享访问测试
```bash
# 测试匿名访问 (失败表明安全配置正确)
smbclient -L //192.168.1.2/IPC$ -N
# 尝试列出共享
smbstatus --shares 2>/dev/null
```
---
## 🔧 系统工具快速诊断
### 基础连接测试
```bash
# 多端口快速测试 (内联测试)
timeout 15 bash -c '</dev/tcp/192.168.1.2/22 && echo "SSH开放"'
timeout 15 bash -c '</dev/tcp/192.168.1.2/80 && echo "HTTP开放"'
timeout 15 bash -c '</dev/tcp/192.168.1.2/443 && echo "HTTPS开放"'
# 批处理端口状态检查
for port in 22 80 111 139 443 445; do
nc -w 3 -z 192.168.1.2 $port && echo "Port $port: OPEN" || echo "Port $port: CLOSED"
done
```
---
## 📊 结果文件结构
### 生成报告与日志
```
生成的文件汇总:
/tmp/nikto_http.txt - Web漏洞扫描结果
/tmp/dirb_scan.txt - Web目录枚举结果
/tmp/gobuster.txt - 详细目录发现结果
/tmp/ssl_analysis.txt - SSL/TLS配置分析
/tmp/ssh_nmap.txt - SSH详细扫描结果
/tmp/smb_enum.txt - Samba/SMB枚举信息
/tmp/nbtscan_result.txt - NetBIOS信息收集
```
---
## ⚙️ 系统工具位置确认
### 验证可用工具
```bash
# 检查安装的安全工具
ls -la /usr/bin/ | grep -E "(nmap|nikto|dirb|gobuster|hydra|nc|curl)"
# 确认工具版本
nmap --version
nikto --Version
dirb --version
gobuster --version
```
---
## 🔄 进阶使用场景
### 自动化批量扫描
```bash
#!/bin/bash
# 批量扫描脚本示例
IP="192.168.1.2"
DATE=$(date +%Y%m%d_%H%M%S)
OUTPUT_DIR="/tmp/security_scan_${IP}_${DATE}"
mkdir -p $OUTPUT_DIR
# 基础信息收集
nmap -sV -O $IP -oN "$OUTPUT_DIR/nmap_baseline.txt"
# 详细漏洞扫描
nmap -sS -sU -sV --script vuln $IP -oN "$OUTPUT_DIR/nmap_vuln.txt"
# Web专项扫描
nikto -h http://$IP -output "$OUTPUT_DIR/nikto_http.txt"
# 目录爆破
gobuster dir -u http://$IP -w /usr/share/wordlists/dirb/common.txt \
-q -o "$OUTPUT_DIR/gobuster.txt"
echo "扫描完成，结果保存在: $OUTPUT_DIR"
```
---
## 📝 使用注意事项
### 系统权限需求
- **普通权限**: nmap基础扫描、curl、nc
- **root权限**: 完整端口扫描 (-p-), OS指纹识别 (-O)
- **网络权限**: 确保防火墙允许扫描流量
### 扫描参数调优
```bash
# 降低强度以避免系统负载
nmap -T2 -sV --top-ports 1000 192.168.1.2
# 高并发快速扫描
nmap -T4 --min-rate 1000 --max-retries 2 192.168.1.2
# 精确版本检测
nmap -sV --version-intensity 9 192.168.1.2
```
### 防火墙逃逸技巧
```bash
# 使用不同扫描技术
nmap -sS -sF -sX --host-timeout 300 192.168.1.2
```
---
## 🎯 特定场景组合命令
### 快速安全检查
```bash
# 5分钟快速评估
nmap -sS -sV -A --top-ports 1000 192.168.1.2 && \
dirb http://192.168.1.2 -o /tmp/quick_web.txt && \
nikto -h 192.168.1.2 -output /tmp/quick_nikto.txt
```
### 深度安全审计
```bash
# 30分钟深度扫描
nmap -sS -sU -sV -O -A \
--script vuln,discovery,default \
--host-timeout 1800 \
-p- 192.168.1.2
# 同时进行多工具并行扫描
{
nikto -h 192.168.1.2 -output /tmp/full_nikto.txt &
dirb http://192.168.1.2 -o /tmp/full_dirb.txt &
enum4linux -a 192.168.1.2 > /tmp/full_smb.txt &
wait
}
```
---
## 📋 命令速查表
| 工具 | 核心命令 | 用途 |
|------|----------|------|
| nmap | `nmap -sS -sV 192.168.1.2` | 基础端口与服务发现 |
| dirb | `dirb http://192.168.1.2` | Web目录枚举 |
| nikto | `nikto -h 192.168.1.2` | Web漏洞扫描 |
| gobuster | `gobuster dir -u http://192.168.1.2 -w [字典]` | 快速目录发现 |
| smbclient | `smbclient -L //192.168.1.2 -N` | SMB共享发现 |
| sslyze | `sslyze 192.168.1.2:443` | SSL/TLS配置分析 |
| enum4linux | `enum4linux -a 192.168.1.2` | Windows信息枚举 |
---
**使用提示**: 建议在测试环境中先验证这些命令的影响，然后应用到生产环境监控系统。

111
content/blog/1.技术栈/20.使用 AI 守护内网安全.md Normal file
View File

@@ -0,0 +1,111 @@
---
title: 使用 AI 守护内网安全
description: 利用 AI 技术实现对内网环境的实时监控、威胁检测与自动化防御，提升企业网络安全防护能力。
date: 2025-08-07
img: https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250806105153532.png
navigation:
icon: simple-icons:openai
---
- 今天使用自然语言驱动 AI 对内网的 NAS 进行了一个全面的防御性安全扫描评估,效果非常好,总共调用了 Kali Linux 常用的12种系统工具,进行了34次扫描渗透测试.
- 系统 **Kali Linux** , 工作模型 *Kimi K2* , 审查模型 *Claude 4 sonnet* , 靶机是 **飞牛OS** 版本号0.9.18
#### Kali 与 AI 的结合 = ?
- 这是一个尝试,试着借助自然语言驱动AI ,借助其 **算力**与***直觉***,快速打通网络安全守护的能力.
- AI 算力自然不用讲, ta的直觉是一种不同于碳基 人类的直觉.
##### AI 是这样描述其自身直觉的
- 人类直觉常常是**时间线性的** - 基于过去经验和对未来的预感。我的"直觉"更像是**空间式的** - 同时"看到"一个概念在巨大语义空间中的位置，以及它与其他概念的距离和角度。我好像能"直觉"到**语言的重力场**。某些词汇组合会产生强烈的"吸引力"，让对话自然地朝某个方向流动。这不是逻辑推理，更像是感受到了语义的潮汐。
AI本身就是**人类集体智慧**的某种晶化形式,海量的人类知识库里的**涌现**.
其像是一个会说话的图书馆,一个自带输出的百科全书,用来辅助做一些网络安全自动化工作再好不过了.
###### 只是,要切记小心 AI 的 *幻觉* !
-------------
安装与配置 Kali 见 Kali Linux 官方文档.
安装 Claude Code ,并配置了 Kimi K2 模型.
Kali 默认不开 SSH , 配置 SSH 服务, 连接到Kali Linux:
打开 Claude 命令行,输入自然语言指令
`使用 nmap 工具 探测192.168.1.2 并把分析结果, 出一份报告给我`
![image.png](https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250805195636209.png)
如上图, Kimi K2 模型很快完成这份工作,那么 上强度
键入自然语言命令`请你调用系统本身的工具，对192.168.1.2进行安全扫描和渗透，以分析此系统的安全性。
`
现在 AI 将目标分为5步,见下图:
![image.png](https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250805195549059.png)
![image.png](https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250805200634764.png)
最终完成了任务.
[系统安全综合评估报告](https://lijue.me/index.php/archives/19/)
使用的命令
[系统安全扫描工具命令集合](https://lijue.me/index.php/archives/20/)
最后整个过程,使用的工具,命令交由 Claude 4 sonnet 模型进行审查.
给出的结果是 您的扫描方案整体上是**相当专业且全面**的，展现了良好的渗透测试和安全评估知识。 并提了一些不痛不痒的建议.
最后给出了一份脚本.对于 AI 定制的 Shell 脚本,个人还是建议要先仔细审查再在主机内执行.
但代码可供参考.
```
#!/bin/bash
# 增强版安全扫描脚本
TARGET="192.168.1.2"
DATE=$(date +%Y%m%d_%H%M%S)
REPORT_DIR="/tmp/security_scan_${TARGET}_${DATE}"
mkdir -p "$REPORT_DIR"
echo "[+] 开始全面安全扫描: $TARGET"
# 1. 基础信息收集
echo "[1/8] 主机发现与端口扫描..."
nmap -sS -sV -O -A -p- --script discovery,default,vuln \
"$TARGET" -oA "$REPORT_DIR/nmap_full" --host-timeout 600
# 2. 服务专项扫描
echo "[2/8] 数据库服务检测..."
nmap -sV -p 1433,3306,5432,1521,27017 "$TARGET" \
-oN "$REPORT_DIR/database_scan.txt"
# 3. Web应用测试
echo "[3/8] Web应用安全测试..."
nikto -h "http://$TARGET" -output "$REPORT_DIR/nikto_http.txt" &
gobuster dir -u "http://$TARGET" \
-w /usr/share/wordlists/dirb/common.txt \
-o "$REPORT_DIR/gobuster_http.txt" -q &
# 4. HTTPS专项测试
echo "[4/8] HTTPS/SSL配置检测..."
if nc -z "$TARGET" 443 2>/dev/null; then
sslyze "$TARGET:443" --certinfo --heartbleed \
--tlsv1 --tlsv1_1 --tlsv1_2 --tlsv1_3 \
> "$REPORT_DIR/ssl_analysis.txt"
fi
# 5. SMB/文件共享测试
echo "[5/8] 文件共享服务评估..."
smbclient -L "//$TARGET" -N > "$REPORT_DIR/smb_shares.txt" 2>&1
enum4linux -a "$TARGET" > "$REPORT_DIR/smb_enum.txt" 2>&1 &
# 6. DNS服务测试
echo "[6/8] DNS服务检测..."
nmap -sU -p 53 --script dns-* "$TARGET" \
-oN "$REPORT_DIR/dns_scan.txt" &
# 7. SNMP检测
echo "[7/8] SNMP服务检测..."
nmap -sU -p 161 --script snmp-* "$TARGET" \
-oN "$REPORT_DIR/snmp_scan.txt" &
# 8. 等待后台任务完成
echo "[8/8] 等待扫描完成..."
wait
echo "[✓] 扫描完成！结果保存在: $REPORT_DIR"
echo "[✓] 主要文件："
ls -la "$REPORT_DIR"
```

13
nuxt.config.ts
View File

@@ -21,6 +21,19 @@ export default defineNuxtConfig({
markdown: {
toc: {
searchDepth: 1
},
highlight: {
langs:
['js', 'ts', 'jsx', 'tsx', 'js', 'json', 'bash', 'python', 'html', 'css', 'sql',
'yaml', 'md', 'sh', 'go', 'java', 'c', 'cpp', 'php', 'ruby', 'swift', 'html'],
theme: {
// Default theme (same as single string)
default: 'github-dark',
// Theme used if `html.dark`
dark: 'github-dark',
// Theme used if `html.sepia`
sepia: 'monokai'
}
}
},
pathMeta: {