前端部署:从开发到生产的最后一公里

前端部署:从开发到生产的最后一公里

毒舌时刻

前端部署?这不是运维的事吗?

"我只负责写代码,部署交给运维"——结果部署失败,互相甩锅,
"我直接把文件上传到服务器"——结果更新不及时,缓存问题频发,
"我用FTP上传,多简单"——结果文件传丢,网站崩溃。

醒醒吧,前端部署是前端开发的重要环节,不是别人的事!

为什么你需要这个?

  • 快速上线:自动化部署,减少人工操作
  • 环境一致性:确保开发、测试、生产环境一致
  • 回滚能力:出现问题时可以快速回滚
  • 监控和日志:实时监控网站状态和错误

反面教材

# 反面教材:手动部署 # 1. 本地构建 npm run build # 2. 手动上传文件 ftp ftp://example.com > put -r dist/* # 3. 手动清除缓存 ssh [email protected] > rm -rf /var/www/html/* > cp -r dist/* /var/www/html/ > systemctl restart nginx # 4. 手动检查 curl https://example.com 

正确的做法

# 正确的做法:使用CI/CD # .github/workflows/deploy.yml name: Deploy to Production on: push: branches: - main jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Setup Node.js uses: actions/setup-node@v3 with: node-version: '18' cache: 'npm' - name: Install dependencies run: npm ci - name: Build run: npm run build - name: Test run: npm test - name: Deploy to Vercel uses: amondnet/vercel-action@v25 with: vercel-token: ${{ secrets.VERCEL_TOKEN }} vercel-args: '--prod' vercel-org-id: ${{ secrets.VERCEL_ORG_ID }} vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }} 
# 正确的做法:使用Docker # Dockerfile FROM node:18-alpine AS build WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build FROM nginx:alpine COPY --from=build /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80 CMD ["nginx", "-g", "daemon off;"] 
# 正确的做法:Nginx配置 # nginx.conf server { listen 80; server_name example.com; root /usr/share/nginx/html; index index.html; # 处理单页应用路由 location / { try_files $uri $uri/ /index.html; } # 静态资源缓存 location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ { expires 30d; add_header Cache-Control "public, max-age=2592000"; } # Gzip压缩 gzip on; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; } 
// 正确的做法:使用CDN // vite.config.js import { defineConfig } from 'vite'; import react from '@vitejs/plugin-react'; export default defineConfig({ plugins: [react()], build: { outDir: 'dist', assetsDir: 'assets', // 生成带哈希的文件名,便于缓存 rollupOptions: { output: { entryFileNames: 'assets/[name].[hash].js', chunkFileNames: 'assets/[name].[hash].js', assetFileNames: 'assets/[name].[hash].[ext]' } } }, // 配置CDN base: 'https://cdn.example.com/' }); 

毒舌点评

看看,这才叫前端部署!不是简单地手动上传文件,而是使用CI/CD、Docker、CDN等现代化工具。

记住,前端部署不是一次性的任务,而是一个持续的过程。你需要考虑构建优化、缓存策略、回滚机制等多个方面。

所以,别再觉得部署是运维的事了,它是你作为前端开发者的责任!

总结

  • CI/CD:使用GitHub Actions、GitLab CI等自动化部署
  • Docker:使用容器化技术,确保环境一致性
  • CDN:使用内容分发网络,提高访问速度
  • 缓存策略:合理设置缓存,减少重复请求
  • 监控:使用监控工具,实时了解网站状态
  • 日志:收集和分析日志,快速定位问题
  • 回滚:准备回滚方案,出现问题时快速恢复
  • 环境变量:使用环境变量管理不同环境的配置

前端部署,让你的代码快速、安全地到达用户手中!

Read more

前端真的能防录屏?EME(加密媒体扩展) DRM 反录屏原理 + 实战代码

前端真的能防录屏?EME(加密媒体扩展) DRM 反录屏原理 + 实战代码

🌷 古之立大事者,不惟有超世之才,亦必有坚忍不拔之志 🎐 个人CSND主页——Micro麦可乐的博客 🐥《Docker实操教程》专栏以最新的Centos版本为基础进行Docker实操教程,入门到实战 🌺《RabbitMQ》专栏19年编写主要介绍使用JAVA开发RabbitMQ的系列教程,从基础知识到项目实战 🌸《设计模式》专栏以实际的生活场景为案例进行讲解,让大家对设计模式有一个更清晰的理解 🌛《开源项目》本专栏主要介绍目前热门的开源项目,带大家快速了解并轻松上手使用 🍎 《前端技术》专栏以实战为主介绍日常开发中前端应用的一些功能以及技巧,均附有完整的代码示例 ✨《开发技巧》本专栏包含了各种系统的设计原理以及注意事项,并分享一些日常开发的功能小技巧 💕《Jenkins实战》专栏主要介绍Jenkins+Docker的实战教程,让你快速掌握项目CI/CD,是2024年最新的实战教程 🌞《Spring Boot》专栏主要介绍我们日常工作项目中经常应用到的功能以及技巧,代码样例完整 👍《Spring Security》专栏中我们将逐步深入Spring Security的各个

黑马程序员java web学习笔记--后端进阶(二)SpringBoot原理

目录 1 配置优先级 2 Bean的管理 2.1 Bean的作用域 2.2 第三方Bean 3 SpringBoot原理 3.1 起步依赖 3.2 自动配置 3.2.1 实现方案 3.2.2 原理分析 3.2.3 自定义starter 1 配置优先级 SpringBoot项目当中支持的三类配置文件: * application.properties * application.yml ❤ * application.yaml 配置文件优先级排名(从高到低):properties配置文件 > yml配置文件 > yaml配置文件 虽然springboot支持多种格式配置文件,但是在项目开发时,推荐统一使用一种格式的配置。

ClawdBot新手教程:通过Web UI修改模型配置并验证生效

ClawdBot新手教程:通过Web UI修改模型配置并验证生效 1. ClawdBot是什么:你的本地AI助手 ClawdBot 是一个可以在你自己的设备上运行的个人 AI 助手。它不依赖云端服务,所有推理都在本地完成,既保护隐私,又避免网络延迟和调用限制。它的后端由 vLLM 提供高性能大模型推理能力,支持高并发、低延迟的文本生成任务。 你不需要懂 Python、不用配 CUDA 环境、也不用写一行部署脚本——只要一台能跑 Docker 的机器(哪怕是树莓派 4),就能把它拉起来,变成你专属的智能工作台。 它不是玩具,也不是 Demo 工程。ClawdBot 的设计目标很实在:把复杂的大模型能力,封装成普通人能点、能改、能信得过的工具。你可以把它看作一个“可配置的 AI 操作系统”:模型是引擎,配置是油门,Web UI

Web 服务与 I/O 模型

一、Web 服务介绍 1.1.1 Apache prefork 模型(预派生模式) * 核心机制:主控制进程派生多个独立子进程,使用select模型,最大并发 1024;每个子进程单线程响应用户请求 * 资源特性:占用内存较多,但稳定性极高 * 配置特点:可设置进程数的最大值和最小值 * 适用场景:访问量中等的场景 * 优缺点 * ✅ 优点:极致稳定,故障隔离性好 * ❌ 缺点:每个请求对应一个进程,资源占用高,并发能力弱,不适合高并发场景 1.1.2 Apache worker 模型(多进程 + 多线程混合模式) * 核心机制:主进程启动多个子进程,每个子进程包含固定线程数;线程处理请求,线程不足时新建子进程补充 * 资源特性:相比 prefork 内存占用更少,支持更高并发