一：看下当前项目在使用 Taro 框架结合 React 开发跨平台小程序时，你遇到过哪些兼容性问题，是如何解决的呢？特别是在微信和支付宝平台之间的差异处理上。
在使用 Taro 框架结合 React 开发跨平台小程序时，微信和支付宝平台之间确实存在一些兼容性问题，以下是常见问题及解决办法：
1. API 差异
不同平台的小程序 API 存在差异，例如获取用户信息的 API。
问题描述：微信使用 wx.getUserProfile，而支付宝使用 my.getAuthCode 结合 my.getUserInfo。 解决办法：使用 Taro 提供的条件编译，根据不同平台调用不同的 API。
import Taro from '@tarojs/taro'
const getUserInfo = async () => {
if (Taro.getEnv() === Taro.ENV_TYPE.WEAPP) {
// 微信平台
const res = await Taro.getUserProfile({ desc: '用于完善会员资料' })
console.log('微信用户信息', res.userInfo)
} else if (Taro.getEnv() === Taro.ENV_TYPE.ALIPAY) {
// 支付宝平台
const authRes = await Taro.alipay.getAuthCode({ scopes:
'auth_user' })
const userRes = await Taro.alipay.getUserInfo({
authCode: authRes.authCode
})
console.log('支付宝用户信息', userRes)
}
}
2. 样式差异
微信和支付宝对部分 CSS 属性的支持和解析存在差异。
问题描述：position: fixed 在支付宝小程序中可能会出现定位不准确的问题。 解决办法：使用 position: absolute 替代 fixed，并结合页面滚动事件动态调整位置。
FixedComponent.jsx
import Taro, { useDidShow, usePageScroll } from '@tarojs/taro'
import { View } from '@tarojs/components'
import './FixedComponent.scss'
const FixedComponent = () => {
const [scrollTop, setScrollTop] = useState(0)
useDidShow(() => {
// 获取初始滚动位置
Taro.pageScrollTo({ scrollTop: 0 })
})
usePageScroll(({ scrollTop }) => {
setScrollTop(scrollTop)
})
return (
<View
className='fixed-component'
style={{ top: 100 + scrollTop + 'px' }}
>
这是一个固定组件
</View>
)
}
export default FixedComponent
3. 图片路径差异
微信和支付宝对图片路径的处理方式不同。
问题描述：在微信中可以使用相对路径，而支付宝可能需要使用绝对路径。 解决办法：使用 Taro 提供的 staticFilesBasePath 配置，统一处理图片路径。
index.js
const config = {
// ...其他配置
staticFilesBasePath: process.env.NODE_ENV === 'production'
? 'https://your-cdn-domain.com'
: '/static'
}
export default config
然后在代码中使用：
jsx
import Taro from '@tarojs/taro'
import { Image } from '@tarojs/components'
const MyImage = () => {
return (
<Image
src={Taro.config.staticFilesBasePath + '/images/logo.png'}
mode='aspectFit'
/>
)
}
export default MyImage
在 Taro 框架里， staticFilesBasePath 是一个用于配置静态资源基础路径的参数。静态资源包含图片、字体文件、音频文件等在项目里不会动态变化的文件。借助设置 staticFilesBasePath ，你能够统一管理不同环境下静态资源的访问路径，像开发环境、测试环境和生产环境等。
作用
- 环境适配 ：在不同环境中，静态资源可能存放在不同的服务器或者路径下。通过 staticFilesBasePath ，可以依据环境动态设置资源路径。
- CDN 支持 ：在生产环境中，为了提高资源加载速度，常常会把静态资源上传到 CDN（内容分发网络）。这时就可以把 staticFilesBasePath 设置为 CDN 的地址。
4. 事件处理差异
不同平台的事件名称和参数存在差异。
问题描述：微信的点击事件是 onClick，支付宝的点击事件是 onTap。 解决办法：Taro 已经对事件进行了统一封装，直接使用 onClick 即可。
jsx
import { View } from '@tarojs/components'
const ClickableComponent = () => {
const handleClick = () => {
console.log('组件被点击了')
}
return (
<View onClick={handleClick}>点击我</View>
)
}
export default ClickableComponent
二：基于 React 18 开发可复用的业务组件，你能详细讲讲在设计这些组件时遵循了哪些原则吗？怎样确保这些组件在不同页面和场景下的稳定性和可扩展性？
在基于 React 18 开发可复用的业务组件时，遵循一些设计原则能够帮助我们创建出稳定、可扩展且易于维护的组件。以下是详细介绍：
设计原则
单一职责原则（SRP）
一个组件应该只负责一个明确的功能或任务。这样可以使组件的代码逻辑更加清晰，易于理解和维护。当需求发生变化时，只需修改相关的组件，而不会影响其他组件。
示例：一个简单的 Button 组件只负责渲染按钮并处理点击事件，而不涉及复杂的业务逻辑。
jsx
// components/Button.jsx
import React from 'react';
const Button = ({ label, onClick }) => {
return (
<button onClick={onClick}>
{label}
</button>
);
};
export default Button;
开放封闭原则（OCP）
组件应该对扩展开放，对修改封闭。也就是说，当需要增加新功能时，应该通过扩展组件来实现，而不是修改原有的代码。在 React 中，可以通过使用 props 和高阶组件（HOC）、自定义 Hook 等方式来实现扩展。
示例：通过 props 扩展 Button 组件的样式。
jsx
// components/Button.jsx
import React from 'react';
const Button = ({ label, onClick, className }) => {
return (
<button onClick={onClick} className={className}>
{label}
</button>
);
};
export default Button;
依赖倒置原则（DIP）
高层模块不应该依赖低层模块，两者都应该依赖抽象。在 React 中，可以通过定义清晰的 props 接口来实现抽象，使组件之间的依赖关系更加灵活。
示例：List 组件依赖于 List.Item 组件的抽象接口，而不是具体实现。
jsx
// components/List.jsx
import React from 'react';
const List = ({ items, renderItem }) => {
return (
<ul>
{items.map((item, index) => (
<li key={index}>{renderItem(item)}</li>
))}
</ul>
);
};
export default List;
接口隔离原则（ISP）
客户端不应该依赖它不需要的接口。在 React 中，组件应该只暴露必要的 props，避免组件之间的耦合度过高。
示例：UserInfo 组件只暴露必要的 props。
jsx
// components/UserInfo.jsx
import React from 'react';
const UserInfo = ({ name, age }) => {
return (
<div>
<p>姓名: {name}</p>
<p>年龄: {age}</p>
</div>
);
};
export default UserInfo;
确保稳定性和可扩展性的方法
编写清晰的 props 类型定义
使用 TypeScript 或 PropTypes 来定义组件的 props 类型，这样可以在开发过程中提前发现类型错误，提高组件的稳定性。
示例（使用 TypeScript） ：
tsx
// components/Button.tsx
import React from 'react';
interface ButtonProps {
label: string;
onClick: () => void;
className?: string;
}
const Button: React.FC<ButtonProps> = ({ label, onClick, className }) => {
return (
<button onClick={onClick} className={className}>
{label}
</button>
);
};
export default Button;
使用状态管理
对于复杂的业务组件，可以使用状态管理库（如 Redux、MobX 或 React Context）来管理组件的状态，避免状态的混乱和难以维护。
示例（使用 React Context） ：
jsx
// context/UserContext.jsx
import React, { createContext, useContext, useState } from 'react';
const UserContext = createContext();
const UserProvider = ({ children }) => {
const [user, setUser] = useState(null);
return (
<UserContext.Provider value={{ user, setUser }}>
{children}
</UserContext.Provider>
);
};
const useUser = () => {
return useContext(UserContext);
};
export { UserProvider, useUser };
编写单元测试
使用测试框架（如 Jest、React Testing Library）编写组件的单元测试，确保组件在不同输入下的输出符合预期，提高组件的稳定性。
示例（使用 Jest 和 React Testing Library） ：
jsx
// __tests__/Button.test.jsx
import React from 'react';
import { render, fireEvent } from '@testing-library/react';
import Button from '../components/Button';
test('Button 点击事件触发', () => {
const mockClick = jest.fn();
const { getByText } = render(<Button label="点击我" onClick={mockClick} />);
const button = getByText('点击我');
fireEvent.click(button);
expect(mockClick).toHaveBeenCalledTimes(1);
});
遵循组件组合模式
将复杂的组件拆分成多个小的、可复用的子组件，通过组件组合的方式来构建复杂的 UI。这样可以提高组件的可扩展性和可维护性。
示例：
jsx
// components/Profile.jsx
import React from 'react';
import UserInfo from './UserInfo';
import Button from './Button';
const Profile = ({ user }) => {
return (
<div>
<UserInfo name={user.name} age={user.age} />
<Button label="编辑信息" onClick={() => console.log('编辑信息')} />
</div>
);
};
export default Profile;
通过遵循这些设计原则和方法，可以开发出稳定、可扩展的可复用业务组件。
三：使用 SCSS 预处理器编写模块化样式，在实际项目中，有没有遇到过样式冲突的情况？如果有，你是如何排查和解决的呢？
在实际项目里使用 SCSS 预处理器编写模块化样式时，确实可能会遇到样式冲突的问题。下面详细介绍可能出现冲突的场景，以及排查和解决方法。
可能出现样式冲突的场景
全局样式污染
当在多个文件中定义同名的全局类名，或者在组件样式里不小心使用了全局作用域的样式，就可能引发样式冲突。例如：
scss
// styles/global.scss
.container {
width: 100%;
padding: 20px;
}
// components/ComponentA.scss
.container {
background-color: blue;
}
嵌套层级过深
在 SCSS 里使用深度嵌套时，可能会产生过于具体的选择器，从而覆盖其他样式。例如：
scss
1
2
3
4
5
6
7
8
// components/ComponentB.scss
.parent {
.child {
.grand-child {
color: red;
}
}
}
排查方法
浏览器开发者工具
借助浏览器的开发者工具（如 Chrome 的开发者工具），可以查看元素的样式应用状况。具体步骤如下：
- 右键点击页面上存在样式问题的元素，选择“检查”。
- 在“Elements”面板里选中该元素，然后在“Styles”面板查看应用到该元素的所有样式规则。
- 查看样式规则的来源文件和行号，以此确定样式冲突的位置。
日志输出
在开发阶段，可以在 SCSS 里使用 @debug 输出调试信息。例如：
scss
$primary-color: blue;
@debug "Primary color is: #{$primary-color}";
.container {
color: $primary-color;
}
解决方法
使用 CSS Modules
CSS Modules 会自动为每个类名生成唯一的哈希值，从而避免样式冲突。在 React 项目中使用 CSS Modules 的示例如下：
组件文件：
MyComponent.jsx
import React from 'react';
import styles from './MyComponent.module.scss';
const MyComponent = () => {
return (
<div className={styles.container}>
<p>这是一个使用 CSS Modules 的组件</p>
</div>
);
};
export default MyComponent;
SCSS 文件：
MyComponent.module.scss
.container {
width: 100%;
padding: 20px;
background-color: lightgray;
}
CSS Modules 是一种让 CSS 类名局部作用域化的技术方案，它可以解决全局 CSS 样式冲突的问题，在前端开发尤其是 React、Vue 等框架中广泛应用。下面从原理、使用方法、优势等方面详细介绍。
原理
在传统的 CSS 里，所有类名都是全局作用域的，不同文件中相同的类名会产生样式冲突。而 CSS Modules 在构建过程中，会自动将每个类名转换为唯一的哈希值，这样类名就具有了局部作用域，避免了样式冲突。
使用方法
1. 项目配置
不同的构建工具配置 CSS Modules 的方式有所不同，以 Webpack 为例，需要在 webpack.config.js 中添加如下配置：
javascript
module.exports = {
module: {
rules: [
{
test: /.module.css$/,
use: [
'style-loader',
{
loader: 'css-loader',
options: {
modules: true
}
}
]
}
]
}
};
如果使用 SCSS，需要添加 sass-loader：
javascript
module.exports = {
module: {
rules: [
{
test: /.module.scss$/,
use: [
'style-loader',
{
loader: 'css-loader',
options: {
modules: true
}
},
'sass-loader'
]
}
]
}
};
2. 创建 CSS 或 SCSS 文件
创建一个以 .module.css 或 .module.scss 结尾的文件，例如 styles.module.scss：
styles.module.scss
.container {
background-color: lightblue;
padding: 20px;
}
.title {
font-size: 24px;
color: #333;
}
3. 在组件中使用
在组件里导入并使用这些局部样式：
MyComponent.jsx
import React from 'react';
import styles from './styles.module.scss';
const MyComponent = () => {
return (
<div className={styles.container}>
<h1 className={styles.title}>欢迎使用 CSS Modules</h1>
</div>
);
};
export default MyComponent;
优势
- 避免样式冲突：每个类名在编译后都是唯一的，不同组件可以使用相同的类名而不会相互影响。
- 模块化开发：样式和组件紧密关联，提高了代码的可维护性和可复用性。
- 易于重构：由于类名的局部作用域，修改样式时不用担心影响其他组件。
注意事项
- 类名的使用方式与传统 CSS 不同，需要通过导入的样式对象来引用。
- 全局样式仍然可以使用，只需不使用 .module.css 或 .module.scss 命名规则即可。
BEM 命名规范
BEM（Block Element Modifier）是一种命名规范，能让类名更具描述性和唯一性。示例如下：
scss
// components/MyComponent.scss
.my-component { // Block
&__title { // Element
font-size: 20px;
}
&--active { // Modifier
background-color: yellow;
}
}
避免全局样式
尽量减少全局样式的使用，若确实需要，可使用命名空间来避免冲突。例如：
scss
// styles/global.scss
.global-styles {
.container {
width: 100%;
padding: 20px;
}
}
限制嵌套层级
建议将 SCSS 的嵌套层级控制在 3 层以内，以降低选择器的特异性。例如：
scss
// components/ComponentB.scss
.parent {
.child {
color: red;
}
}
通过上述排查和解决方法，可以有效避免和处理使用 SCSS 编写模块化样式时出现的样式冲突问题。
四：搭建多环境配置体系，你是如何保证开发、测试、生产环境之间配置的准确性和一致性的？有没有遇到过因为环境配置问题导致的线上故障，又是如何处理的呢？
保证多环境配置准确性和一致性的方法
1. 配置文件分离
将不同环境的配置分别存放在不同的文件中，这样可以清晰区分各环境的配置项。以常见的前端项目为例，在项目里创建 config 目录，包含 dev.js、test.js 和 prod.js 三个文件，分别对应开发、测试和生产环境。
dev.js
module.exports = {
API_URL: 'http://dev-api.example.com',
DEBUG: true
};
test.js
应用
1
2
3
4
module.exports = {
API_URL: 'http://test-api.example.com',
DEBUG: false
};
prod.js
应用
1
2
3
4
module.exports = {
API_URL: 'http://api.example.com',
DEBUG: false
};
在主配置文件中依据环境变量加载对应的配置：
index.js
const env = process.env.NODE_ENV;
let config;
switch (env) {
case 'development':
config = require('./dev');
break;
case 'test':
config = require('./test');
break;
case 'production':
config = require('./prod');
break;
default:
config = require('./dev');
}
module.exports = config;
2. 版本控制
把配置文件纳入版本控制系统（如 Git），保证每个环境的配置都有记录，方便回溯和对比。同时，使用分支管理不同环境的配置，例如 dev 分支管理开发环境配置，test 分支管理测试环境配置，master 分支管理生产环境配置。
3. 环境变量管理
借助环境变量来区分不同环境，避免在代码里硬编码环境信息。在构建脚本中设置环境变量，例如在 package.json 里配置不同环境的构建命令：
json
{
"scripts": {
"dev": "NODE_ENV=development webpack-dev-server",
"test": "NODE_ENV=test webpack --mode production",
"build": "NODE_ENV=production webpack --mode production"
}
}
4. 配置验证
在代码中添加配置验证逻辑，保证加载的配置项符合预期。可以使用 joi 等库进行配置验证：
javascript
const Joi = require('joi');
const schema = Joi.object({
API_URL: Joi.string().uri().required(),
DEBUG: Joi.boolean().required()
});
const { error } = schema.validate(config);
if (error) {
throw new Error(`配置验证失败: ${error.details[0].message}`);
}
收起代码
5. 自动化测试
编写自动化测试用例，覆盖不同环境下的配置使用场景，确保配置在各环境中都能正常工作。
处理因环境配置问题导致的线上故障
1. 故障发现
借助监控系统（如 Sentry、New Relic 等）及时发现线上故障。监控系统可以捕获异常信息、性能指标等，帮助快速定位问题。
2. 故障隔离
一旦发现故障，立即将受影响的服务进行隔离，避免故障扩散。可以通过负载均衡器将流量从故障实例中移除。
3. 问题定位
查看日志文件、监控数据和配置文件，确定问题根源。检查环境变量是否正确设置，配置文件是否被误修改等。
4. 紧急修复
如果是配置错误，迅速恢复到正确的配置。可以从版本控制系统中找回正确的配置文件，重新部署服务。
5. 根本原因分析
故障解决后，进行根本原因分析，找出导致配置问题的原因，制定预防措施，避免类似问题再次发生。例如，加强配置文件的权限管理，增加配置变更的审批流程等。
6. 经验总结
将故障处理过程和预防措施记录下来，分享给团队成员，提高整个团队对环境配置问题的认识和处理能力。
五：封装通用工具类和插件系统实现业务逻辑解耦和复用，在这个过程中，你是如何评估哪些业务逻辑适合封装成工具类或插件的呢？有没有遇到过封装后发现不适配某些特殊业务场景的情况，又是如何优化的？
评估哪些业务逻辑适合封装成工具类或插件
- 复用性
- 高频使用 ：当某段业务逻辑在多个地方频繁使用时，就适合封装成工具类或插件。例如，在一个电商项目中，计算商品总价（包含折扣、运费等）的逻辑可能会在购物车页面、订单确认页面等多处使用，将其封装成工具类可以避免代码重复。
- 跨项目复用 ：如果某些逻辑在不同项目中都有应用的可能性，也值得封装。比如日期格式化、数据验证等通用功能，封装成独立的工具类或插件后，能在多个项目中复用。
- 独立性
- 功能单一 ：符合单一职责原则的业务逻辑适合封装。例如，一个处理图片压缩的功能，它只负责图片压缩这一单一任务，将其封装成工具类可以让代码结构更清晰，便于维护和测试。
- 与其他模块低耦合 ：当一段业务逻辑与其他模块的依赖关系较少时，封装成工具类或插件会更方便。比如，一个生成随机验证码的函数，它不依赖于特定的业务数据或组件，独立性强，适合封装。
- 稳定性
- 逻辑稳定 ：如果业务逻辑相对稳定，不经常发生变化，那么封装成工具类或插件是合适的。例如，基本的数学运算函数，其逻辑不会轻易改变，封装后可以长期使用。
- 可配置性
- 需要灵活配置 ：当业务逻辑需要根据不同的场景进行灵活配置时，封装成插件系统可以更好地满足需求。例如，一个表单验证插件，不同的表单可能有不同的验证规则，通过插件的配置选项可以轻松实现。
封装后不适配特殊业务场景及优化方法
- 遇到的问题 在实际开发中，可能会遇到封装后的工具类或插件无法满足某些特殊业务场景的情况。例如，封装了一个通用的表格组件，支持基本的表格展示和排序功能，但在某个特殊页面需要添加复杂的筛选逻辑，原有的表格组件无法直接支持。
- 优化方法 扩展配置项
- 为工具类或插件添加更多的配置选项，使其能够适应不同的业务需求。例如，在上述表格组件中，可以添加一个 customFilters 配置项，允许用户传入自定义的筛选逻辑。
class TableComponent {
constructor(options) {
this.options = {
data: [],
columns: [],
customFilters: null,
...options
};
}
applyFilters() {
if (this.options.customFilters) {
return this.options.customFilters(this.options.data);
}
// 默认筛选逻辑
return this.options.data;
}
}
继承和扩展
- 通过继承工具类或插件，重写或添加方法来满足特殊需求。例如，创建一个新的表格组件类，继承自原有的通用表格组件类，并添加特殊的筛选功能。
import TableComponent from './TableComponent';
class SpecialTableComponent extends TableComponent {
constructor(options) {
super(options);
}
applyFilters() {
// 实现特殊的筛选逻辑
const filteredData = this.options.data.filter(item => {
// 特殊筛选条件
return item.status === 'active';
});
return filteredData;
}
}
插件机制
- 在工具类或插件中设计插件机制，允许用户通过插件来扩展功能。例如，为表格组件添加插件接口，用户可以编写自定义插件来实现特殊的筛选逻辑。
class TableComponent {
constructor(options) {
this.options = options;
this.plugins = [];
}
use(plugin) {
this.plugins.push(plugin);
}
applyFilters() {
let data = this.options.data;
this.plugins.forEach(plugin => {
if (plugin.filter) {
data = plugin.filter(data);
}
});
return data;
}
}
// 使用示例
const table = new TableComponent({ data: [...] });
table.use({
filter: (data) => {
return data.filter(item => item.status === 'active');
}
});
通过以上方法，可以在封装通用工具类和插件系统时，更好地评估适合封装的业务逻辑，并在遇到不适配特殊业务场景时进行有效的优化。
六：将日期格式化、数据验证等通用功能封装成独立的工具类或插件后，在多个项目中复用不一定是简单地复制到新项目，下面介绍几种常见的复用方式：
1. 直接复制
这是最直接的方式，把封装好的工具类或插件文件直接复制到新项目对应的目录下。 适用场景
- 项目之间相对独立，复用的代码不需要频繁更新。
- 小规模项目，没有复杂的依赖管理和版本控制需求。 示例 假设在旧项目中有一个日期格式化的工具函数 dateUtils.js ：
export function formatDate(date, format = 'YYYY-MM-DD') {
const d = new Date(date);
const year = d.getFullYear();
const month = String(d.getMonth() + 1).padStart(2, '0');
const day = String(d.getDate()).padStart(2, '0');
if (format === 'YYYY-MM-DD') {
return `${year}-${month}-${day}`;
}
// 其他格式处理...
}
将这个文件复制到新项目的 utils 目录下，然后在新项目中使用：
import { formatDate } from './utils/dateUtils';
const formatted = formatDate(new Date());
console.log(formatted);
2. 使用包管理工具
借助 npm 或 yarn 等包管理工具，把封装好的工具类或插件发布成一个独立的 npm 包，然后在不同项目中通过包名进行安装和使用。 适用场景
- 多个项目需要复用代码，且代码需要频繁更新和维护。
- 团队协作开发，需要统一管理和版本控制。 步骤
- 初始化包 ：在封装好的工具类或插件目录下执行 npm init 或 yarn init 初始化一个 package.json 文件。
- 发布包 ：使用 npm publish 或 yarn publish 将包发布到 npm 仓库（需要先在 npm 官网注册账号并登录）。
- 安装和使用 ：在新项目中使用 npm install your-package-name 或 yarn add your-package-name 安装包，然后在代码中引入使用。
3. 使用 Git 子模块
Git 子模块允许你将一个 Git 仓库作为另一个 Git 仓库的子目录，这样可以在主项目中引用外部仓库的代码。 适用场景
- 复用的代码有独立的版本控制需求，且与主项目的开发相对独立。
- 多个项目需要跟踪复用代码的不同版本。 步骤
- 添加子模块 ：在主项目中执行 git submodule add ，将外部仓库添加为子模块。
- 更新子模块 ：在主项目中使用 git submodule update --init --recursive 初始化和更新子模块。
- 使用子模块代码 ：在主项目中直接引用子模块目录下的代码。 综上所述，直接复制只是复用方式之一，你可以根据项目的实际需求和场景选择合适的复用方式。
七：1. 从前端性能优化的角度来看，在这个小程序项目中，你做了哪些工作？效果如何，有没有相关的数据可以支撑？
在基于 Taro 框架开发的小程序项目里，可从多个方面进行前端性能优化，以下为你介绍常见的优化手段、预期效果及验证方式：
1. 代码分包 优化工作
小程序通常有主包和分包的概念，将不同功能模块拆分成多个分包，避免主包过大。在 Taro 里，可在 config/index.js 里配置分包信息。
// ... 已有代码 ...
const baseConfig = {
// ... 已有配置 ...
subpackages: [
{
root: 'subpackage1',
pages: [
'pages/page1',
'pages/page2'
]
}
]
};
// ... 已有代码 ...
效果及数据支撑 通过代码分包，主包体积明显减小，首次加载速度加快。假设主包原本体积为 2MB，拆分成一个 1MB 主包和一个 1MB 分包后，首次加载时间可能从 3 秒缩短至 1.5 秒。可通过小程序开发者工具的「性能面板」查看加载时间。
2. 图片优化 优化工作
- 格式选择 ：使用 WebP 格式图片替代 JPEG 或 PNG，WebP 格式在保持相似质量的前提下体积更小。
- 压缩处理 ：使用图片压缩工具（如 TinyPNG）对图片进行压缩。
- 懒加载 ：在 Taro 里使用 Image 组件的 lazyLoad 属性实现图片懒加载。
import { Image } from '@tarojs/components';
const MyComponent = () => {
return (
<Image
src={Taro.config.staticFilesBasePath + '/images/logo.png'}
mode='aspectFit'
lazyLoad
/>
);
};
export default MyComponent;
效果及数据支撑 图片优化后，页面加载时的网络请求量减少，整体加载速度提升。例如，将一组总大小为 5MB 的 JPEG 图片替换为 WebP 格式后，总大小变为 2MB，页面加载时间可从 5 秒缩短至 3 秒。可通过浏览器开发者工具的「Network」面板查看图片加载时间和大小。
3. 减少不必要的渲染 优化工作
- 使用 React.memo ：对于纯函数组件，使用 React.memo 包裹，避免不必要的重渲染。
import React from 'react';
const MyComponent = React.memo(({ data }) => {
return (
<div>{data}</div>
);
});
export default MyComponent;
- 避免频繁的 setState ：合并多次 setState 操作，减少组件重渲染次数。 效果及数据支撑 减少不必要的渲染后，CPU 使用率降低，页面响应速度加快。可通过小程序开发者工具的「性能面板」查看渲染时间和 CPU 使用率。
4. 缓存策略 优化工作
使用小程序的缓存 API（如 Taro.setStorage 和 Taro.getStorage ）缓存一些不经常变化的数据，减少网络请求。
// 获取数据
const getData = async () => {
try {
const cachedData = await Taro.getStorage({ key: 'cachedData' });
if (cachedData) {
return cachedData;
}
const freshData = await fetchDataFromServer();
await Taro.setStorage({ key: 'cachedData', data: freshData });
return freshData;
} catch (error) {
console.error('获取数据失败', error);
}
};
效果及数据支撑 使用缓存策略后，重复访问页面时的网络请求次数减少，加载时间缩短。例如，原本每次访问页面需要 2 秒的网络请求时间，使用缓存后，第二次访问时间可缩短至 0.5 秒。可通过浏览器开发者工具的「Network」面板查看网络请求次数和时间。
