一、小程序开发
1.1 小程序的授权登录流程
小程序的授权需要使用按钮的 open-type 开发能力，获取用户信息，然后可以通过 bindgetuserinfo 绑定一个方法，拿到用户的授权信息，授权成功后，需要使用 wx.login 获取临时的 code 码，然后发送给后台接口，后台拿到后去请求微信的服务器获取 openid 和 sessionkey，并返回给前端登录凭证。
1.2 刘海屏适配问题
通过配置app.json的window属性的navigationStyle，改为custom模式，来自定义导航栏。
1.3 小程序性能优化
代码包体积优化：
- 分包加载：将小程序分为主包和多个分包，减少首次加载时间
- 及时清理无用资源：移除未使用的图片、组件、代码
- 压缩图片：使用合适的图片格式和压缩工具
渲染性能优化：
- 列表渲染优化：使用
wx:key提高列表渲染性能 - 避免在
onPageScroll中执行复杂操作 - 适当使用
setData的分段加载 - 合理使用
IntersectionObserver替代scroll-view滚动监听
网络请求优化：
- 使用请求合并和请求缓存
- 预加载关键数据
- 合理使用本地缓存
二、APP项目
2.1 APP项目技术点
技术点难点：
- 登录
- 手机验证码
- 第三方登录
- 地图
- 分享
- 支付
- 购物车
- 定位
- 订单生成
普通的知识点：
Vuex、Axios组件封装- 路由传参
- 导航守卫
token处理
2.2 跨端开发框架
Flutter：
- Google推出的跨平台UI框架
- 使用
Dart语言 - 自带渲染引擎，性能接近原生
- 丰富的 Material Design 组件库
React Native：
- Facebook推出的跨平台框架
- 使用
JavaScript和React - 通过原生组件实现跨平台
- 活跃的社区和丰富的第三方库
uni-app：
- DCloud推出的跨平台框架
- 使用
Vue.js开发 - 一套代码多端发布
- 编译到小程序、H5、App等多端
2.3 移动端适配
响应式布局：
- 使用
flexbox布局 - 媒体查询适配不同屏幕
rem/vw/vh单位
高清适配：
DPR（设备像素比）适配- 图片高清适配（
@2x、@3x） 1px边框问题解决方案
三、认证授权
3.1 OAUTH认证授权
OAuth 认证授权就三个步骤，三句话可以概括：
- 获取未授权的
Request Token - 获取用户授权的
Request Token - 用授权的
Request Token换取Access Token
3.2 SSO单点登录
SSO（Single Sign-On）：
- 用户只需登录一次即可访问多个应用系统
- 减少用户重复输入凭证的麻烦
- 提高系统安全性（统一身份管理）
实现方式：
Session同步：共享用户登录状态Token传递：JWT等令牌机制CAS协议：Central Authentication Service
3.3 JWT认证
JWT（JSON Web Token）：
- 一种用于身份验证的开放标准
- 由三部分组成：
Header、Payload、Signature - 无状态、可扩展
JWT结构：
// Header
{ "alg": "HS256", "typ": "JWT" }
// Payload
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022,
"exp": 1516242622
}
// Signature
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret
)JWT优缺点：
| 优点 | 缺点 |
|---|---|
| 无状态，易于扩展 | 一旦签发无法撤销 |
| 可跨域使用 | 载荷信息有限 |
| 便于微服务架构 | 需要注意过期时间设置 |
四、微前端
4.1 微前端概述
定义：微前端是一种将大型前端应用拆分为多个独立、可复用子应用的架构风格，每个子应用可以独立开发、测试、部署。
核心理念：
- 技术栈无关：各子应用可以使用不同的前端框架
- 独立开发：团队可以独立负责各自的子应用
- 独立部署：子应用可以单独上线，不需要整体发布
- 增量升级：逐步替换旧系统，降低迁移风险
适用场景：
- 大型前端项目的团队协作
- 老项目向新技术的渐进式迁移
- 多团队并行开发的大型系统
4.2 主流微前端方案
4.2.1 qiankun
方案简介：
qiankun采用运行时集成主、子应用，HTML Entry 作为子应用入口的中心路由基座式微前端方案。qiankun基于 single-spa 实现，主、子应用都可以做到技术栈无关，方便接入子应用；完整的应用生命周期管理，子应用只需要暴露生命周期钩子即可实现应用接入。
运行时集成：
运行时的最大优点是主、子应用间解耦，实现技术栈无关；发布时不需要整个系统重新构建发布。它的不足之处在于存在资源重复加载的情况，但是可以通过 HTTP 缓存等方式解决部分框架层资源共享的问题。
样式隔离解决方案：
- HTML Entry 方式：应用卸载后，会同时卸载其样式表，做到样式的隔离。因为浏览器会对所有样式表的插入、移除做整个 CSS、DOM 的重构，从而达到插入、卸载样式的目的
- 约定开发规范：如子应用不能侵入（如动态增加全局样式等）修改除本应用外的样式；子应用样式写在以子应用名作为命名空间的类里等
JS污染解决方案：
qiankun有提供JS沙箱机制，解决JS全局变量的污染，实现子应用间的软隔离。
qiankun主应用配置：
// main.js
import { registerMicroApps, start } from "qiankun";
registerMicroApps([
{
name: "vueApp",
entry: "//localhost:8081",
container: "#container",
activeRule: "/vue",
},
{
name: "reactApp",
entry: "//localhost:8082",
container: "#container",
activeRule: "/react",
},
]);
start();qiankun子应用配置：
// 子应用必须导出的生命周期钩子
export async function mount(props) {
// 渲染应用
ReactDOM.render(<App />, document.getElementById("root"));
}
export async function unmount() {
// 卸载应用
ReactDOM.unmountComponentAtNode(document.getElementById("root"));
}4.2.2 single-spa
定义：最早的微前端框架，定义了子应用接入的规范和生命周期。
核心概念：
- API：
registerApplication、bootstrap、mount、unmount - 路由系统：通过 URL 决定加载哪个子应用
- 生命周期：bootstrap(初始化) → mount(挂载) → unmount(卸载)
优点：
- 轻量级，学习成本低
- 最早提出微前端概念
- 兼容各种框架
缺点：
- 功能相对简单，需要自行封装更多功能
- 没有内置样式隔离和JS沙箱
- 需要手动处理更多边界情况
4.3 样式隔离
CSS Modules：
- 将 CSS 类名编译为唯一的哈希值
- 避免样式冲突
- 需要构建工具支持
BEM 命名规范：
- Block、Element、Modifier
- 子应用使用统一前缀区分
- 示例：
appName__element--modifier
Shadow DOM：
- Web Components 的样式封装特性
- 完全隔离的 DOM 和样式树
- 兼容性需要注意
动态样式表：
- qiankun 的
HTML Entry方式 - 应用卸载时自动卸载其样式表
- 利用浏览器
CSSOM特性
4.4 JS沙箱机制
快照沙箱：
- 在应用挂载前记录全局状态
- 卸载时恢复全局状态
- 适合单实例场景
代理沙箱：
- 使用
Proxy拦截全局操作 - 不修改真实的
window对象 - 支持多实例并行运行
qiankun沙箱：
- 内置JS沙箱机制
- 解决全局变量污染
- 实现子应用间的软隔离
4.5 应用间通信
Props 传递：
- 主应用通过
props向子应用传递数据 - 适合父子应用间的数据共享
EventBus：
- 使用事件总线进行通信
- 简单直观
- 需要注意事件清理和命名空间
Shared Module：
- 抽取公共模块供各应用共享
- 使用
Webpack联邦模块 - 状态管理库共享
BroadcastChannel：
- 原生浏览器 API
- 同源页面间通信
- 可用于主应用与子应用通信
