初始前端2

layout->router->view （layout中使用index连接router中的文件路径，使用view指明渲染位置，而不是指明要渲染的文件，在路径router中已经指明了需要渲染的文件）

ref定义的动态响应模型可以动态追加属性

liru：    const a= rfe({   name:'', job:''})

那么在外围可以动态添加属性，即时：a.value.time=time是正确的，动态追加（作用范围呢）

正常的请求（通过axios异步请求）

要编写对应的代理文件，根据路径判断是走前端还是后端

1.在api文件中的对应的.js文件中写入（本质上就是到处结果）

语法：export const 方法名（形参）=>request.请求方式（请求路径，参数）

export const addApi(emp)=>request.post('/emps',emp)

2.在对应的的.vue文件中导入，在需要使用时直接调用结果 const result= await addApi(参数) 要在外围方法上加async，可以根据结果掉用其中的 code msg data等属性（返回值属性）

2.el-upload（原生的异步请求，不用手动导入，可直接调用结果，服务器返回的数据作为第一个参数传递给该回调。）

el-upload 组件通过原生 XHR 实现文件上传，并自动处理服务器响应。当上传成功时，会将服务器返回的数据直接传递给 on-success 回调函数，你可以在回调中处理这些数据（如更新 Vue 响应式对象）。这种方式无需手动编写 XHR 代码，也不需要引入 axios，简化了文件上传的实现。

虽然 axios 更常用，但 el-upload 组件内置了 XHR 实现，无需额外依赖。两者的核心区别：

通过返回参数赋值到前端，进行展示

为什么必须用date[]数组？（前端中间件要求，

date是个过渡性质，前端：date数组，后端：begin， end）

date[]数组是为了适配前端组件的特性，而begin和end是为了适配后端的数据格式。通过 “数组→拆分→合并” 的流程，实现了前后端和组件的无缝衔接。如果直接使用begin和end，会导致el-date-picker无法正常工作（因为组件不支持分别绑定两个字段）。

前端监听，拆分（因为前端接受的是date数组，传回后端要拆分）
watch(
  () => employee.value.exprList,
  (newValue) => {
    employee.value.exprList.forEach((expr) => {
      if (expr.date && expr.date.length) {
        expr.begin = expr.date[0];  // 数组第一项赋值给begin
        expr.end = expr.date[1];    // 数组第二项赋值给end
      }
    });
  },
  { deep: true }
);

//从后端获取数据时，date时为null的要把，begin 与end组装到date
// 编辑回显时，将后端的begin和end合并为date数组
employee.value.exprList.forEach((expr) => {
  expr.date = [expr.begin, expr.end];  // 合并为数组，供组件绑定
});

为什么使用 localStorage要强转化为string（序列化与反序列化），其他正常操作，在内存上

1. 数据类型限制：

• localStorage 只能存字符串，无法直接存储对象、数组、函数等。
• JSON.stringify()会忽略对象中的函数、undefined、Symbol等无法序列化的属性。

• 内存操作：直接读写对象，无需转换。
• localStorage 操作：存时序列化（JSON.stringify()），读时反序列化（JSON.parse()）。

总结：内存操作就像是在草稿纸上记录东西，操作灵活但数据容易丢失；而localStorage持久化存储则像是把信息写在笔记本上，数据可以长期保存，但存储和读取时需要遵循特定的格式要求。

对于复杂的数据结构，在存储到localStorage时一定要先进行 JSON 序列化，读取后再进行反序列化。这样才能保证数据的完整性，避免出现数据丢失或者无法正确解析的问题。