src/main/java/com/yeqifu/bus/controller/BusinessController.java

@@ -75,4 +75,5 @@ public class BusinessController {
         return "business/salesback/salesbackManager";
     }// 返回视图名称，跳转到商品销售退货管理页面
 
-}
+}
+//git提交测试

src/main/java/com/yeqifu/bus/controller/CustomerController.java

@@ -29,12 +29,34 @@ import java.util.List;
  * @author luoyi-
  * @since 2019-12-05
  */
-@RestController
-@RequestMapping("/customer")
-public class CustomerController {
 
-    @Autowired
-    private ICustomerService customerService;
+    /*
+     * CustomerController类在整个基于Spring Boot（通常配合Spring MVC）构建的Web项目架构中扮演着至关重要的角色，它充当了客户端与后端业务逻辑层之间的桥梁，
+     * 负责接收、解析来自客户端（如浏览器、移动端应用等通过HTTP协议发起的请求）的各种与客户相关的请求，并根据请求类型及携带的参数等信息，
+     * 调用相应的业务逻辑方法进行处理，最后将处理结果以合适的格式（如JSON格式等，因为使用了@RestController注解）返回给客户端，完成一次请求响应交互过程。
+     *
+     * @RestController注解是Spring 4.0之后引入的一个组合注解，它相当于同时添加了@Controller和@ResponseBody注解，
+     * 意味着这个类中的所有请求处理方法返回的数据都会直接写入HTTP响应体中（而不是返回视图名称等，常用于构建RESTful API），并且会根据返回值类型进行相应的序列化操作，
+     * 例如返回一个Java对象时，会自动将其转换为JSON格式（如果项目中配置了合适的JSON序列化器，如Jackson等）返回给客户端，方便客户端直接解析使用。
+     *
+     * @RequestMapping("/customer")注解用于对该控制器类下的所有请求处理方法进行统一的请求路径映射管理，规定了所有与客户相关的请求路径都要以"/customer"为前缀，
+     * 例如，后续可能会有"/customer/getById"用于根据客户ID获取客户信息的请求路径、"/customer/save"用于保存新客户信息的请求路径等，
+     * 这样的路径规划方式有助于构建清晰、规范的API接口体系，便于客户端开发人员理解和调用，也方便后端进行接口的维护与扩展。
+     *
+     * @Autowired注解用于实现Spring框架中的依赖注入功能，在这里它将ICustomerService接口的实现类自动装配到customerService属性上。
+     * ICustomerService作为一个定义了客户业务逻辑的接口，其具体的实现类（可能由其他开发人员编写，实现了接口中规定的诸如保存客户、更新客户、删除客户、查询客户等各种方法）
+     * 承载着实际的客户业务处理逻辑，比如与数据库交互进行数据的持久化操作、进行业务规则验证（如客户信息格式是否合法等）等功能。
+     * 通过注入这个接口的实现类，CustomerController就能在各个请求处理方法中方便地调用这些业务逻辑方法，将客户端的请求转化为具体的业务操作，
+     * 进而完成整个客户相关业务的请求响应流程，实现前后端的数据交互与业务协同，确保整个项目中客户相关功能的正常运作。
+     */
+    @RestController
+    @RequestMapping("/customer")
+    public class CustomerController {
+
+        // 通过Spring框架提供的@Autowired注解，让Spring容器自动查找并注入ICustomerService接口的实现类到此处的customerService属性，
+        // 这是一种解耦的设计方式，使得控制器类不需要关心具体的业务逻辑实现细节，只需要调用接口定义的方法即可，方便后续的代码维护、替换业务逻辑实现类等操作。
+        @Autowired
+        private ICustomerService customerService;
 
     /**
      * 查询所有的客户
@@ -42,16 +64,51 @@ public class CustomerController {
      * @return
      */
     @RequestMapping("loadAllCustomer")
-    public DataGridView loadAllCustomer(CustomerVo customerVo){
-        //1.声明分页page对象
-        IPage<Customer> page = new Page<Customer>(customerVo.getPage(),customerVo.getLimit());
-        //2.声明queryWrapper
+    /*
+     * 此方法用于处理名为"loadAllCustomer"的请求（通常是HTTP请求，基于Spring MVC或Spring Boot的Web应用场景下），
+     * 其主要功能是根据传入的查询条件（通过CustomerVo对象传递），分页查询并返回所有符合条件的客户信息，最终以DataGridView对象的形式返回结果，
+     * 该对象包含了查询到的客户数据以及总记录数等信息，方便前端进行展示和分页操作等处理。
+     *
+     * 接收一个CustomerVo类型的参数customerVo，CustomerVo应该是一个用于封装客户查询相关条件的视图对象，包含了如页码、每页显示数量、客户姓名、联系人姓名、电话号码等可能用于筛选客户的信息。
+     */
+    public DataGridView loadAllCustomer(CustomerVo customerVo) {
+        // 1. 声明分页page对象
+        /*
+         * 创建一个IPage<Customer>类型的分页对象page，使用传入的CustomerVo对象中的页码（customerVo.getPage()）和每页显示的记录数（customerVo.getLimit()）进行初始化。
+         * IPage接口通常是由一些持久化框架（如MyBatis-Plus等）提供的，用于实现分页功能，它会在后续与数据库交互查询客户信息时，按照设定的页码和每页记录数来获取相应的数据。
+         */
+        IPage<Customer> page = new Page<Customer>(customerVo.getPage(), customerVo.getLimit());
+
+        // 2. 声明queryWrapper
+        /*
+         * 创建一个QueryWrapper<Customer>对象queryWrapper，QueryWrapper是一种用于构建查询条件的工具类（同样常见于MyBatis-Plus等框架中）。
+         * 它可以方便地通过链式调用的方式添加各种查询条件，用于在后续查询客户数据时，从数据库中筛选出符合特定条件的客户记录。
+         */
         QueryWrapper<Customer> queryWrapper = new QueryWrapper<Customer>();
-        queryWrapper.like(StringUtils.isNotBlank(customerVo.getCustomername()),"customername",customerVo.getCustomername());
-        queryWrapper.like(StringUtils.isNotBlank(customerVo.getConnectionpersion()),"connectionpersion",customerVo.getConnectionpersion());
-        queryWrapper.like(StringUtils.isNotBlank(customerVo.getPhone()),"phone",customerVo.getPhone());
-        customerService.page(page,queryWrapper);
-        return new DataGridView(page.getTotal(),page.getRecords());
+
+        // 根据传入的CustomerVo对象中客户姓名是否不为空（StringUtils.isNotBlank用于判断字符串非空且非空白字符），
+        // 如果不为空，则添加一个模糊查询条件到queryWrapper中，按照客户姓名（"customername"字段）进行模糊匹配查询，匹配的值为customerVo.getCustomername()。
+        // 这样在查询数据库时，就能筛选出客户姓名包含指定关键字的客户记录，实现根据客户姓名进行模糊查询的功能。
+        queryWrapper.like(StringUtils.isNotBlank(customerVo.getCustomername()), "customername", customerVo.getCustomername());
+
+        // 类似地，根据传入的CustomerVo对象中联系人姓名是否不为空，若不为空则添加模糊查询条件，按照联系人姓名（"connectionpersion"字段）进行模糊匹配查询，
+        // 以此来筛选出联系人姓名包含指定关键字的客户记录，满足按照联系人姓名进行模糊查询的业务需求。
+        queryWrapper.like(StringUtils.isNotBlank(customerVo.getConnectionpersion()), "connectionpersion", customerVo.getConnectionpersion());
+
+        // 按照同样的逻辑，针对传入的CustomerVo对象中的电话号码字段，如果电话号码不为空，就添加模糊查询条件，以电话号码（"phone"字段）进行模糊匹配查询，
+        // 便于从数据库中查找出电话号码包含指定内容的客户记录，实现根据电话号码进行模糊查询的功能。
+        queryWrapper.like(StringUtils.isNotBlank(customerVo.getPhone()), "phone", customerVo.getPhone());
+
+        // 调用customerService的page方法，将前面创建并设置好的分页对象page和查询条件封装对象queryWrapper传入。
+        // customerService应该是一个实现了与客户业务逻辑相关的服务层接口（例如实现了ICustomerService接口等），
+        // 其内部的page方法会基于传入的分页和查询条件，与数据库进行交互（可能借助MyBatis-Plus等持久化框架），执行实际的分页查询操作，
+        // 将查询到的符合条件的客户记录填充到page对象中，并同时更新page对象中的总记录数等相关属性。
+        customerService.page(page, queryWrapper);
+
+        // 创建一个DataGridView对象并返回，将page对象中的总记录数（page.getTotal()）和当前页查询到的客户记录列表（page.getRecords()）作为参数传入。
+        // DataGridView对象大概率是用于向前端传递数据的一种视图模型，它整合了总记录数和具体的客户数据，方便前端进行分页展示、数据渲染等操作，
+        // 从而将查询到的所有符合条件的客户信息以及总记录数等关键数据返回给前端，完成整个查询并返回数据的业务流程。
+        return new DataGridView(page.getTotal(), page.getRecords());
     }
 
     /**
@@ -60,12 +117,31 @@ public class CustomerController {
      * @return
      */
     @RequestMapping("addCustomer")
-    public ResultObj addCustomer(CustomerVo customerVo){
+    /*
+     * 此方法用于处理名为"addCustomer"的请求（通常在基于Spring MVC或Spring Boot构建的Web应用场景下，处理来自客户端的HTTP请求），
+     * 其核心功能是将传入的客户相关信息（通过CustomerVo对象封装）添加到数据库中，实现新增客户的业务操作。
+     * 最后根据操作执行情况返回对应的结果对象ResultObj，用于告知客户端添加操作是成功还是出现了错误。
+     *
+     * 接收一个CustomerVo类型的参数customerVo，CustomerVo应该是一个用于承载要添加的客户各种信息的视图对象，它包含了如客户姓名、联系方式、地址等客户相关属性信息，
+     * 这些信息会被传递到后续的业务逻辑层用于构建完整的客户实体并保存到数据库中。
+     */
+    public ResultObj addCustomer(CustomerVo customerVo) {
         try {
+            // 调用customerService的save方法，尝试将传入的customerVo对象所封装的客户信息保存到数据库中。
+            // customerService应该是一个实现了与客户业务逻辑相关的服务层接口（例如实现了ICustomerService接口等），
+            // 其内部的save方法会对传入的CustomerVo对象进行必要的处理（可能包括数据校验、转换为对应的Customer实体对象等操作），
+            // 然后借助相关的持久化框架（如MyBatis、MyBatis-Plus等）将客户信息持久化到数据库中，完成新增客户的实际操作。
             customerService.save(customerVo);
+            // 如果保存操作顺利完成，没有抛出异常，就返回ResultObj.ADD_SUCCESS，表示客户信息添加成功的结果对象，
+            // 该对象应该是一个预定义的、用于统一返回结果格式的枚举类型或者普通类实例（具体取决于项目中的实现方式），方便前端根据返回值判断操作是否成功。
             return ResultObj.ADD_SUCCESS;
         } catch (Exception e) {
+            // 如果在保存客户信息的过程中出现了任何异常情况（比如数据库连接异常、数据格式不符合约束条件等），
+            // 会进入到catch块中进行异常处理。
             e.printStackTrace();
+            // 在这里先打印出异常的堆栈信息，方便开发人员在调试时查看具体的出错原因和出错位置，
+            // 然后返回ResultObj.ADD_ERROR，表示客户信息添加失败的结果对象，告知客户端添加操作出现了错误，
+            // 以便前端进行相应的提示或者后续的错误处理操作。
             return ResultObj.ADD_ERROR;
         }
     }
@@ -76,46 +152,102 @@ public class CustomerController {
      * @return
      */
     @RequestMapping("updateCustomer")
-    public ResultObj updateCustomer(CustomerVo customerVo){
+    /*
+     * 此方法用于处理名为"updateCustomer"的请求，在基于Spring MVC或Spring Boot构建的Web应用场景下，主要负责接收客户端发送的更新客户信息的请求。
+     * 其核心业务逻辑是依据传入的CustomerVo对象（该对象封装了需要更新的客户相关信息以及用于定位客户记录的关键标识，比如客户ID等），
+     * 调用相关业务服务层的方法来更新数据库中对应的客户记录，最终根据更新操作的执行情况，返回相应的结果对象ResultObj，以告知客户端更新操作是成功还是失败。
+     *
+     * 接收的参数CustomerVo customerVo是一个视图对象，它包含了要更新的客户各项信息，例如客户姓名、联系方式、地址等，同时也应该包含了能唯一确定要更新哪条客户记录的标识信息（通常是客户ID），
+     * 这些信息会传递给后续的业务逻辑层进行具体的更新操作处理。
+     */
+    public ResultObj updateCustomer(CustomerVo customerVo) {
         try {
+            // 调用customerService的updateById方法，尝试根据传入的CustomerVo对象所携带的信息来更新数据库中对应的客户记录。
+            // customerService大概率是实现了与客户业务逻辑相关的服务层接口（比如ICustomerService接口等）的一个具体实现类实例，
+            // 其内部的updateById方法会先从CustomerVo对象中提取关键的更新信息以及用于定位客户记录的标识（例如ID属性），
+            // 然后借助相应的持久化框架（如MyBatis、MyBatis-Plus等）构建合适的更新语句（例如SQL的UPDATE语句等），
+            // 依据这些信息去数据库中查找并更新对应的客户记录，将CustomerVo中包含的新的客户信息替换原记录中的旧信息，完成实际的更新操作。
             customerService.updateById(customerVo);
+            // 如果更新操作顺利完成，没有抛出任何异常，就返回ResultObj.UPDATE_SUCCESS，表示客户信息更新成功的结果对象。
+            // ResultObj应该是项目中预先定义好的用于统一表示操作结果的一种数据结构（可能是枚举类型或者普通类等形式），方便前端开发人员依据此返回值来判断更新操作是否成功，
+            // 进而在前端界面上做出相应的提示或者进行后续的业务处理。
             return ResultObj.UPDATE_SUCCESS;
         } catch (Exception e) {
+            // 如果在执行更新客户记录的过程中出现了任何异常情况，比如数据库连接异常、违反数据约束条件（如唯一性约束等）、数据格式错误等，
+            // 就会进入到catch块中进行异常处理。
             e.printStackTrace();
+            // 在这里先打印出异常的堆栈信息，这有助于开发人员在调试阶段快速定位问题所在，查看具体是哪个环节出现了错误以及错误的详细情况，
+            // 然后返回ResultObj.UPDATE_ERROR，表示客户信息更新失败的结果对象，以便告知客户端此次更新操作出现了问题，
+            // 使得前端可以做出相应的提示给用户或者进行其他的错误处理逻辑，比如提示用户重新尝试更新等操作。
             return ResultObj.UPDATE_ERROR;
         }
     }
-
     /**
      * 删除一个客户
      * @param id 客户的ID
      * @return
      */
-    @ApiOperation(value = "删除一个客户",notes = "删除一个客户")
-    @ApiImplicitParams({@ApiImplicitParam(name = "id", value = "客户ID",required = true,paramType = "query",dataType = "Integer")})
-    @RequestMapping(value = "deleteCustomer",method = RequestMethod.DELETE)
-    public ResultObj deleteCustomer(Integer id){
+    // 使用Swagger相关的注解@ApiOperation来描述这个接口方法的功能，向使用接口文档的人员（如前端开发人员、其他后端对接人员等）说明此方法是用于删除一个客户的操作。
+// 同时，通过notes属性进一步补充说明信息，这里同样强调了是执行删除一个客户的功能。
+    @ApiOperation(value = "删除一个客户", notes = "删除一个客户")
+// @ApiImplicitParams注解用于详细定义接口方法的隐含参数信息，这里使用@ApiImplicitParam注解定义了一个名为"id"的参数。
+// 说明该参数代表客户ID，是必须要传入的（required = true），参数传递方式为query（即通过URL的查询参数形式传递，例如?id=123这种形式），
+// 并且其数据类型为Integer，表示该参数接收的是整型数据，以此向接口文档使用者清晰展示参数的要求和相关属性。
+    @ApiImplicitParams({@ApiImplicitParam(name = "id", value = "客户ID", required = true, paramType = "query", dataType = "Integer")})
+// 使用@RequestMapping注解来映射HTTP请求，将这个方法与"deleteCustomer"这个请求路径进行关联，并且指定请求方法为DELETE，
+// 表明此接口是用于接收并处理DELETE类型的HTTP请求，符合RESTful风格的接口设计，专门用于执行删除客户的操作。
+    @RequestMapping(value = "deleteCustomer", method = RequestMethod.DELETE)
+    public ResultObj deleteCustomer(Integer id) {
         try {
+            // 调用customerService的deleteCustomerById方法，尝试依据传入的客户ID（参数id）来删除数据库中对应的客户记录。
+            // customerService应该是一个实现了与客户业务逻辑相关服务的类实例，其内部的deleteCustomerById方法会按照既定的业务规则和持久化机制（可能借助数据库框架等），
+            // 先根据传入的ID在数据库中查找并确认对应的客户记录，然后执行删除操作，比如构建SQL的DELETE语句等方式来从数据库中移除该客户记录，完成实际的删除客户的业务逻辑。
             customerService.deleteCustomerById(id);
+            // 如果删除操作顺利完成，没有抛出任何异常，就返回ResultObj.DELETE_SUCCESS，表示客户删除成功的结果对象。
+            // ResultObj大概率是项目中预先定义好的用于统一表示各种操作结果的一种数据结构（可能是枚举类型或者特定的类等形式），
+            // 方便前端或其他调用此接口的地方依据返回值来判断删除操作是否成功，进而进行后续的业务处理，比如前端给出相应的提示信息告知用户客户已成功删除等。
             return ResultObj.DELETE_SUCCESS;
         } catch (Exception e) {
+            // 如果在执行删除客户记录的过程中出现了任何异常情况，例如数据库连接异常、违反外键约束（若客户记录与其他数据表存在关联关系时）、权限不足等问题，
+            // 就会进入到catch块中进行异常处理。
             e.printStackTrace();
+            // 在这里先打印出异常的堆栈信息，这有助于开发人员在调试阶段快速定位问题所在，查看具体是哪个环节出现了错误以及错误的详细情况，
+            // 然后返回ResultObj.DELETE_ERROR，表示客户删除失败的结果对象，以便告知客户端或者其他调用此接口的地方此次删除操作出现了问题，
+            // 使得前端可以做出相应的提示给用户（如提示用户删除失败，请稍后再试等）或者进行其他的错误处理逻辑。
             return ResultObj.DELETE_ERROR;
         }
     }
 
-
     /**
      * 加载所有客户的下拉列表
      * @return
      */
     @RequestMapping("loadAllCustomerForSelect")
-    public DataGridView loadAllCustomerForSelect(){
+    /*
+     * 此方法用于处理名为"loadAllCustomerForSelect"的请求（通常在基于Spring MVC或Spring Boot构建的Web应用场景下，处理来自客户端的HTTP请求），
+     * 其核心功能是从数据库中查询出所有可用的客户信息，并以特定的视图格式（DataGridView）返回给客户端，方便前端进行展示或者供其他业务逻辑使用，例如用于下拉框选择等场景展示可用客户列表。
+     */
+    public DataGridView loadAllCustomerForSelect() {
+        // 创建一个QueryWrapper<Customer>对象queryWrapper，QueryWrapper是一种常用于构建查询条件的工具类（常见于MyBatis-Plus等框架中），
+        // 它可以通过链式调用的方式方便地添加各种查询条件，用于后续从数据库中筛选出符合特定要求的客户记录。
         QueryWrapper<Customer> queryWrapper = new QueryWrapper<Customer>();
+
+        // 使用queryWrapper的eq方法添加一个相等性的查询条件，即查询数据库中"available"字段值等于Constast.AVAILABLE_TRUE的客户记录。
+        // 这里的Constast.AVAILABLE_TRUE应该是一个常量（可能在Constast类中定义），代表客户处于可用状态的标识值，通过这个条件可以筛选出所有可用的客户，
+        // 过滤掉那些不可用的客户记录，满足只获取可用客户信息的业务需求。
         queryWrapper.eq("available", Constast.AVAILABLE_TRUE);
+
+        // 调用customerService的list方法，将构建好的查询条件封装对象queryWrapper传入。
+        // customerService应该是一个实现了与客户业务逻辑相关的服务层接口（例如实现了ICustomerService接口等）的具体实现类实例，
+        // 其内部的list方法会依据传入的查询条件，借助相关的持久化框架（如MyBatis、MyBatis-Plus等）与数据库进行交互，执行实际的查询操作，
+        // 从数据库中查找出所有满足条件（即"available"字段值等于指定可用状态值）的客户记录，并将这些客户记录封装成一个List<Customer>集合返回。
         List<Customer> list = customerService.list(queryWrapper);
+
+        // 创建一个DataGridView对象并返回，将查询到的包含所有可用客户信息的List<Customer>集合作为参数传入。
+        // DataGridView对象大概率是用于向前端传递数据的一种视图模型，它接收客户数据列表，方便前端进行展示、数据渲染等操作，
+        // 从而将所有可用客户的信息以合适的格式返回给前端，完成整个查询并返回可用客户数据的业务流程。
         return new DataGridView(list);
     }
-
-}
+    }
+    //git提交测试
 

src/main/java/com/yeqifu/bus/controller/GoodsController.java

@@ -182,3 +182,136 @@ public class GoodsController {
 
 }
 
+// GoodsController类，使用了@RestController注解，表明它是Spring框架下用于构建RESTful API的控制器类，主要负责处理与商品（Goods）相关的各种HTTP请求，
+// 并将处理结果以合适的格式（如JSON）返回给客户端（通常是前端应用），在前后端交互中起着关键的桥梁作用，方便前端对商品信息进行查询、添加、修改、删除等操作。
+// 通过@RequestMapping("/goods")注解，为该控制器下所有的请求映射路径设置了公共前缀"/goods"，便于对商品相关的接口进行统一管理和分类，便于代码维护以及前端接口调用。
+
+
+    // 使用@Autowired注解自动注入IGoodsService接口的实现类对象，通过这个服务对象，可以调用与商品相关的核心业务逻辑方法，
+    // 例如分页查询商品信息、添加商品、更新商品信息、删除商品以及获取库存预警商品等操作，具体的业务实现细节则在IGoodsService接口对应的实现类中完成，这里只是进行调用触发相应的业务逻辑流程。
+
+
+    // 通过@Autowired注解注入IProviderService接口的实现类对象，用于获取供应商相关的业务服务。在查询商品信息、加载可用商品等操作时，借助该服务根据供应商ID查询供应商的详细信息，
+    // 以便将供应商名称等相关信息补充到商品记录中，使返回给前端的数据更加完整，方便前端展示和业务操作时能呈现更全面的供应商相关情况，让用户清楚知道商品对应的供应商是谁。
+
+
+    /**
+     * 查询商品
+     * @param goodsVo 这是一个封装了查询条件的对象，通常包含分页相关信息（如页码、每页显示数量）以及其他筛选条件（如供应商ID、商品名称、产品编码、助记码、描述、规格等），由前端传入，
+     * 方便后端统一处理各种不同的查询需求，根据这些条件从数据库中准确获取符合要求的商品记录。
+     * @return 返回一个DataGridView对象，该对象一般是项目中自定义用于封装数据展示相关信息的，其中包含了查询到的商品记录的总数量以及具体的商品记录列表，
+     * 方便前端进行分页展示以及对数据进行进一步的处理和分析等操作，例如前端可以根据这些数据展示商品列表、进行数据统计等。
+     */
+
+        // 创建一个IPage对象，用于实现分页功能，通过传入从goodsVo对象中获取的当前页码（goodsVo.getPage()）和每页显示记录数量（goodsVo.getLimit()）来确定分页范围，
+        // 例如，当页码为2且每页显示数量为10时，表示要获取第2页，每页显示10条商品记录的那部分数据，这样可以对大量的商品记录进行分页管理，提升前端展示效果以及用户查看数据的体验。
+
+
+        // 创建一个QueryWrapper对象，用于构建查询条件，它类似于构建SQL语句中的WHERE子句部分，能够灵活地添加各种筛选条件，从而精确地查询出符合特定要求的商品记录。
+
+
+        // 对供应商进行查询，如果从goodsVo对象中获取的供应商ID（goodsVo.getProviderid()）不为空且不等于0，说明前端传入了供应商筛选条件，
+        // 则添加一个相等性查询条件，在数据库表中对应"providerid"字段，查找与传入的供应商ID相等的商品记录，以此实现按供应商来筛选商品信息的功能，方便查看特定供应商提供的商品情况。
+
+        // 对商品名称进行模糊查询，如果从goodsVo对象中获取的商品名称（goodsVo.getGoodsname()）不为空字符串（通过StringUtils.isNotBlank方法判断），
+        // 则添加一个模糊查询条件，在数据库表中对应"goodsname"字段，查找包含传入商品名称的商品记录，便于根据部分商品名称来查找相关商品，满足更灵活的查询需求。
+
+        // 对产品编码进行模糊查询，同理，当goodsVo对象中获取的产品编码（goodsVo.getProductcode()）不为空字符串时，添加一个模糊查询条件，
+        // 在数据库表的"productcode"字段上进行模糊匹配，查找包含传入产品编码的商品记录，方便根据产品编码来定位商品。
+
+        // 对助记码进行模糊查询，若goodsVo对象中获取的助记码（goodsVo.getPromitcode()）不为空字符串，就在"promitcode"字段添加模糊查询条件，
+        // 查找包含传入助记码的商品记录，有助于通过助记码快速查找特定商品，提高查询的便捷性。
+
+        // 对商品描述进行模糊查询，当goodsVo对象中获取的描述信息（goodsVo.getDescription()）不为空字符串时，添加一个模糊查询条件，
+        // 在数据库表的"description"字段进行模糊匹配，查找包含传入描述内容的商品记录，方便根据商品的相关描述来查找商品。
+
+        // 对商品规格进行模糊查询，类似地，若goodsVo对象中获取的规格信息（goodsVo.getSize()）不为空字符串，就在"size"字段添加模糊查询条件，
+        // 查找包含传入规格的商品记录，便于根据商品规格来筛选商品，满足不同业务场景下对商品数据的查询需求。
+
+        // 通过商品的ID对查询结果进行降序排序，添加一个按照"id"字段（推测是商品的唯一标识符字段）进行降序排序的条件，使得查询返回的商品记录按照ID从大到小的顺序排列，
+        // 这样在前端展示时，用户能先看到较新添加或更新的商品记录，更符合一般的数据查看习惯，方便查看和分析近期的商品情况。
+        // 调用goodsService的page方法，传入构建好的分页对象page和查询条件包装器queryWrapper，服务层会根据这些条件执行数据库查询操作，
+        // 获取符合条件的商品数据，并将数据填充到page对象中，例如设置page对象中的总记录数、当前页的记录列表等属性，以便后续返回完整的分页数据信息。
+
+        // 获取查询结果中当前页的商品记录列表，方便后续对每条记录进行补充相关信息的操作，比如添加供应商名称等，使返回给前端的数据更加丰富详细，更具业务价值。
+
+        // 遍历当前页查询到的每条商品记录，为每条记录补充供应商名称信息，使其展示的数据更加完整全面，方便前端展示以及业务查看和操作使用。
+            // 通过providerService的getById方法，根据当前商品记录中的供应商ID（goods.getProviderid()）从数据库中查询对应的供应商详细信息，获取到一个Provider对象（如果存在的话）。
+                // 如果查询到了对应的供应商信息，将供应商的名称设置到当前商品记录（goods）中，以便前端展示商品记录时能同时显示供应商名称，让数据更直观、完整，便于业务人员查看商品对应的供应商情况。
+
+
+        // 创建一个DataGridView对象，将查询得到的商品记录的总数量（通过page.getTotal()获取）以及当前页补充完整信息后的商品记录列表（page.getRecords()）进行封装，
+        // 最终返回给前端，使得前端能够按照分页逻辑展示商品信息，并且展示的数据包含了丰富的关联信息（供应商名称等），满足业务查看和操作的实际需求。
+
+    /**
+     * 添加商品
+     * @param goodsVo 这是一个包含了要添加的商品相关信息的对象，通常由前端传入，里面封装了如商品名称、供应商ID、产品编码、助记码、描述、规格、商品图片等诸多与商品业务相关的属性信息，
+     * 这些信息将被保存到数据库中，形成一条新的商品记录。
+     * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了诸如ADD_SUCCESS、ADD_ERROR等枚举值，用于明确表示添加商品操作的成功或失败状态，
+     * 方便前端根据接收到的返回结果进行相应的提示操作或者后续处理，比如提示用户添加成功或者告知添加失败的原因等。
+     */
+
+            // 打印商品图片相关信息（可能用于调试查看图片相关情况，比如确认前端传入的图片路径等是否正确），此处输出只是辅助开发阶段查看相关数据情况，在正式环境可根据需求决定是否保留。
+
+
+            // 判断商品图片路径是否不为空且以"_temp"结尾，如果满足该条件，说明可能是临时的图片文件名，需要进行重命名处理。
+
+                // 调用AppFileUtils的renameFile方法对临时的商品图片文件名进行重命名操作，得到新的文件名，并将新文件名设置回goodsVo对象的"goodsimg"属性中，
+                // 以便后续保存商品信息时使用正确的图片文件名，保证图片存储和关联的正确性。
+
+
+            // 调用goodsService的save方法，将包含完整商品信息（已处理好图片文件名等情况）的goodsVo对象传递过去，触发服务层中处理添加商品的业务逻辑，
+            // 该逻辑可能涉及到向数据库的商品表中插入一条新记录、将商品图片存储到指定的文件存储位置（如果有图片存储相关逻辑）以及其他关联业务模块的数据交互等一系列复杂操作，
+            // 如果整个操作过程顺利完成，不会抛出异常；若在执行过程中出现问题（比如数据库插入失败、文件存储失败、业务规则校验不通过等情况），则会抛出异常。
+
+            // 如果在添加商品的过程中出现异常，通过打印异常堆栈信息（这有助于开发人员在排查问题时了解详细的异常发生位置和原因），
+            // 然后返回表示添加商品失败的ResultObj.ADD_ERROR结果对象给前端，使得前端能够知晓操作未成功，进而采取相应的提示告知用户或者其他补救措施等。
+
+
+    /**
+     * 修改商品
+     * @param goodsVo 这是一个包含了要修改的商品新信息的对象，通常由前端传入，里面的属性值是修改后的值，通过与数据库中已存在的商品记录的主键等信息进行匹配来确定要更新的具体记录，
+    // 例如修改商品名称、规格、图片等信息后，将新的值封装在这个对象中传递过来进行更新操作。
+     * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了如UPDATE_SUCCESS、UPDATE_ERROR等枚举值，用于表示修改商品操作的成功或失败状态，
+     * 方便前端根据返回结果进行相应的处理或提示用户，比如提示用户更新成功或者告知更新失败的原因等。
+     */
+
+            // 判断商品图片是否不是默认图片，这里通过判断图片路径不为空且不等于默认图片路径（Constast.DEFAULT_IMG_GOODS，应该是项目中定义的表示默认商品图片的常量）来确定，
+            // 如果不是默认图片，说明可能需要进行图片相关的更新处理操作，比如更换了商品图片等情况。
+
+
+                // 进一步判断商品图片路径是否以"_temp"结尾，如果是，说明可能是新上传的临时图片文件名，需要进行重命名处理，以符合实际存储和使用的规范。
+
+                    // 调用AppFileUtils的renameFile方法对临时的商品图片文件名进行重命名操作，得到新的文件名，并将新文件名设置回goodsVo对象的"goodsimg"属性中，
+                    // 确保后续更新商品信息时使用正确的图片文件名进行关联。
+
+
+                    // 获取原先商品记录中的图片路径，通过调用goodsService的getById方法根据商品ID（goodsVo.getId()）获取对应的商品记录，再获取其图片路径（getGoodsimg方法），
+                    // 以便后续删除原来的旧图片，避免图片文件冗余，保持文件存储与商品信息的一致性。
+
+                    // 调用AppFileUtils的removeFileByPath方法，根据获取到的旧图片路径删除原先的商品图片文件，实现图片文件的更新替换操作。
+
+
+            // 调用goodsService的updateById方法，将包含更新后商品信息的goodsVo对象传递过去，服务层会根据对象中的主键信息（通常是商品记录的ID），
+            // 在数据库中找到对应的商品记录，并将其他属性值更新为goodsVo对象中传入的新值，实现更新商品信息的功能，例如修改商品记录中的名称、规格等字段的值，
+            // 如果更新操作顺利完成则无异常抛出，若出现问题（比如找不到对应记录、更新数据违反约束等情况）则会抛出异常。
+
+            // 如果在更新商品信息的过程中出现异常，打印异常堆栈信息（便于开发人员排查问题根源），然后返回表示更新操作失败的ResultObj.UPDATE_ERROR结果对象给前端，
+            // 让前端知晓更新操作未成功，以便采取相应的提示或者其他处理措施，比如告知用户更新失败，可尝试再次操作等。
+
+
+    /**
+     * 删除商品
+     * @param id 要删除的商品记录的唯一标识符（通常是主键ID），由前端传入，通过这个ID来确定要从数据库中删除的具体商品记录。
+     * @param goodsimg 商品图片的路径，用于定位要删除的商品图片文件，确保在删除商品记录的同时，将对应的商品图片文件也从存储中删除，保持数据的一致性。
+     * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了如DELETE_SUCCESS、DELETE_ERROR等枚举值，用于表示删除商品操作的成功或失败状态，
+     * 方便前端根据返回结果进行相应的处理或提示用户，比如提示用户删除成功或者告知删除失败的原因等。
+     */
+
+            // 调用AppFileUtils的removeFileByPath方法，根据传入的商品图片路径（goodsimg）删除对应的商品图片文件，实现删除商品图片的操作，
+            // 避免商品记录删除后图片文件仍残留，浪费存储空间且可能导致数据不一致的问题。
+
+            // 调用goodsService的deleteGoodsById方法（假设该方法用于根据商品ID删除商品记录，具体实现逻辑在IGoodsService接口对应的实现类中），传入要删除的商品ID，
+            // 服务层会根据这个ID在数据库中找到对应的商品记录并执行删除操作，实现删除商品记录的功能，
+            // 如果删除操作顺利完成则无异常抛出，若出现问题（比如存在关联数据、违反数据库约束等情况）则会抛出异常。
+

src/main/java/com/yeqifu/bus/controller/InportController.java

@@ -139,3 +139,129 @@ public class InportController {
 
 }
 
+
+// InportController类，使用了@RestController注解，表明它是Spring框架下用于构建RESTful API的控制器类，主要负责处理与商品进货（Inport）相关的HTTP请求，
+// 并将处理结果以合适的格式（如JSON）返回给客户端（通常是前端应用），起到了在前后端之间传递和处理商品进货业务数据的桥梁作用。同时，通过@RequestMapping("inport")注解，
+// 为该控制器下所有的请求映射路径设置了公共前缀"inport"，便于对商品进货相关的接口进行统一管理和分类，方便前端进行接口调用以及后端进行代码维护。
+
+
+    // 使用@Autowired注解自动注入IInportService接口的实现类对象，通过这个服务对象，可以调用与商品进货相关的核心业务逻辑方法，
+    // 比如分页查询进货记录、添加进货商品、更新进货商品信息以及删除进货商品等操作，具体的业务实现细节则在IInportService接口对应的实现类中完成，这里只是进行调用触发相应的业务逻辑流程。
+
+
+    // 通过@Autowired注解注入IProviderService接口的实现类对象，用于获取供应商相关的业务服务。在查询商品进货信息时，借助该服务根据供应商ID查询供应商的详细信息，
+    // 以便将供应商姓名等相关信息补充到进货记录中，使返回给前端的数据更加完整，方便前端展示和业务操作时能呈现更全面的供应商相关情况，例如让用户清楚知道每笔进货对应的供应商是谁。
+
+    // 同样使用@Autowired注解注入IGoodsService接口的实现类对象，用于获取商品相关的业务服务。在处理进货记录查询结果或者添加、更新进货商品信息时，通过该服务依据商品ID查询商品详情（如商品名称、规格等），
+    // 然后将这些商品相关信息设置到进货记录中，进一步丰富返回给前端的数据内容，让前端能够展示更详细的商品相关信息，便于业务查看和分析商品进货情况，比如了解进货的具体商品是什么以及其规格特点等。
+
+
+    /**
+     * 查询商品进货
+     * @param inportVo 这是一个封装了查询条件的对象，通常包含分页相关信息（如页码、每页显示数量）以及其他筛选条件（如供应商ID、商品ID、时间范围等），由前端传入，
+     * 方便后端统一处理各种不同的查询需求，根据这些条件从数据库中准确获取符合要求的商品进货记录。
+     * @return 返回一个DataGridView对象，该对象一般是项目中自定义用于封装数据展示相关信息的，其中包含了查询到的商品进货记录的总数量以及具体的进货记录列表，
+     * 方便前端进行分页展示以及对数据进行进一步的处理和分析等操作，例如前端可以根据这些数据展示进货记录列表、进行数据统计等。
+     */
+
+        // 创建一个IPage对象，用于实现分页功能，通过传入从inportVo对象中获取的当前页码（inportVo.getPage()）和每页显示记录数量（inportVo.getLimit()）来确定分页范围，
+        // 例如，当页码为2且每页显示数量为10时，表示要获取第2页，每页显示10条商品进货记录的那部分数据，这样可以对大量的进货记录进行分页管理，提升前端展示效果以及用户查看数据的体验。
+
+        // 创建一个QueryWrapper对象，用于构建查询条件，它类似于构建SQL语句中的WHERE子句部分，能够灵活地添加各种筛选条件，从而精确地查询出符合特定要求的商品进货记录。
+
+        // 对供应商进行查询，如果从inportVo对象中获取的供应商ID（inportVo.getProviderid()）不为空且不等于0，说明前端传入了供应商筛选条件，
+        // 则添加一个相等性查询条件，在数据库表中对应"providerid"字段，查找与传入的供应商ID相等的进货记录，以此实现按供应商来筛选进货信息的功能，方便查看特定供应商的进货情况，例如查看某个供应商的历史进货记录。
+
+        // 对商品进行查询，同理，当inportVo对象中获取的商品ID（inportVo.getGoodsid()）不为空且不等于0时，表明前端传入了商品筛选条件，
+        // 就在数据库表的"goodsid"字段添加相等性查询条件，查找与传入商品ID匹配的进货记录，便于根据具体商品来查询其进货情况，满足不同业务场景下对商品进货数据的查询需求，比如查看某类商品的进货频次、数量等情况。
+
+
+        // 对时间进行查询要求大于开始时间小于结束时间，当inportVo对象中的开始时间（inportVo.getStartTime()）不为空时，添加一个大于等于（ge）的查询条件，
+        // 在数据库表的"inporttime"字段（推测是商品进货时间字段）上，筛选出进货时间大于等于传入的开始时间的进货记录；同样，当结束时间（inportVo.getEndTime()）不为空时，
+        // 添加一个小于等于（le）的查询条件，筛选出进货时间小于等于传入的结束时间的进货记录，这样就能获取到处于指定时间范围内的商品进货信息，方便按时间区间进行数据查询、统计分析等操作，
+        // 例如查看某个时间段内的进货总量、不同供应商在该时间段的进货情况等。
+
+
+        // 通过进货时间对商品进行排序，添加一个按照"inporttime"字段（商品进货时间）进行降序排序的条件，使得查询返回的进货记录按照进货时间从近到远的顺序排列，
+        // 这样在前端展示时，用户能先看到较新的进货记录，更符合一般的数据查看习惯，方便查看和分析近期的进货情况，有助于及时掌握最新的进货动态、发现潜在问题等。
+
+        // 调用inportService的page方法，传入构建好的分页对象page和查询条件包装器queryWrapper，服务层会根据这些条件执行数据库查询操作，
+        // 获取符合条件的商品进货数据，并将数据填充到page对象中，例如设置page对象中的总记录数、当前页的记录列表等属性，以便后续返回完整的分页数据信息。
+
+        // 获取查询结果中当前页的进货记录列表，方便后续对每条记录进行补充相关信息的操作，比如添加供应商姓名、商品名称和规格等，使返回给前端的数据更加丰富详细，更具业务价值。
+
+        // 遍历当前页查询到的每条商品进货记录，为每条记录补充供应商姓名、商品名称和规格等信息，使其展示的数据更加完整全面，方便前端展示以及业务查看和操作使用。
+
+            // 通过providerService的getById方法，根据当前进货记录中的供应商ID（inport.getProviderid()）从数据库中查询对应的供应商详细信息，获取到一个Provider对象（如果存在的话）。
+
+
+                // 如果查询到了对应的供应商信息，将供应商的姓名设置到当前进货记录（inport）中，以便前端展示进货记录时能同时显示供应商姓名，让数据更直观、完整，便于业务人员查看相关供应商的进货情况。
+
+            // 通过goodsService的getById方法，依据当前进货记录中的商品ID（inport.getGoodsid()）从数据库中查询对应的商品详细信息，获取到一个Goods对象（若存在的话）。
+
+
+                // 如果查询到了商品信息，将商品的名称设置到当前进货记录（inport）中，方便前端展示进货记录时能呈现商品名称，使数据更具可读性，便于了解进货商品的具体情况。
+
+                // 同时将商品的规格信息也设置到当前进货记录（inport）中，进一步丰富进货记录展示的数据内容，方便业务人员更详细地掌握进货商品的规格特点等信息。
+
+
+
+        // 创建一个DataGridView对象，将查询得到的商品进货记录的总数量（通过page1.getTotal()获取）以及当前页补充完整信息后的进货记录列表（page1.getRecords()）进行封装，
+        // 最终返回给前端，使得前端能够按照分页逻辑展示商品进货信息，并且展示的数据包含了丰富的关联信息（供应商姓名、商品名称和规格等），满足业务查看和操作的实际需求。
+
+
+    /**
+     * 添加进货商品
+     * @param inportVo 这是一个包含了要添加的进货商品相关信息的对象，通常由前端传入，里面封装了如商品ID、供应商ID、进货数量、进货价格等诸多与进货业务相关的属性信息，
+     * 这些信息将被保存到数据库中，形成一条新的进货记录。
+     * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了诸如ADD_SUCCESS、ADD_ERROR等枚举值，用于明确表示添加进货商品操作的成功或失败状态，
+     * 方便前端根据接收到的返回结果进行相应的提示操作或者后续处理，比如提示用户添加成功或者告知添加失败的原因等。
+     */
+
+            // 获得当前系统用户，通过从WebUtils获取当前会话（HttpSession），并从中获取名为"user"的属性（推测是在用户登录成功后将用户信息存储在了会话中），
+            // 然后将其强制转换为User类型，这样就能获取到当前操作的用户对象，后续可以利用该用户信息记录是谁进行了此次进货操作等相关业务逻辑。
+
+            // 设置操作人，将获取到的当前用户的姓名（通过user.getName()获取）设置到inportVo对象中，用于记录此次进货操作是由哪个用户执行的，
+            // 这样在数据库的进货记录中就能明确体现操作人信息，方便后续进行操作记录查询、责任追溯等业务需求。
+
+
+            // 设置进货时间，创建一个新的Date对象（代表当前时间），并将其设置到inportVo对象的"inporttime"属性中，以此记录此次进货业务发生的具体时间，
+            // 确保进货记录中的时间信息准确无误，便于后续按照时间进行数据查询、统计分析等操作。
+
+            // 调用inportService的save方法，将包含完整进货信息（已设置好操作人、进货时间等）的inportVo对象传递过去，触发服务层中处理添加进货商品的业务逻辑，
+            // 该逻辑可能涉及到向数据库的进货表中插入一条新记录、更新库存数量（增加对应商品的库存）以及其他关联业务模块的数据交互等一系列复杂操作，
+            // 如果整个操作过程顺利完成，不会抛出异常；若在执行过程中出现问题（比如数据库插入失败、业务规则校验不通过等情况），则会抛出异常。
+
+            // 如果在添加进货商品的过程中出现异常，通过打印异常堆栈信息（这有助于开发人员在排查问题时了解详细的异常发生位置和原因），
+            // 然后返回表示添加进货商品失败的ResultObj.ADD_ERROR结果对象给前端，使得前端能够知晓操作未成功，进而采取相应的提示告知用户或者其他补救措施等。
+
+
+    /**
+     * 更新进货商品
+     * @param inportVo 这是一个包含了要更新的进货商品新信息的对象，通常由前端传入，里面的属性值是修改后的值，通过与数据库中已存在的进货记录的主键等信息进行匹配来确定要更新的具体记录，
+     * 例如修改进货数量、进货价格等信息后，将新的值封装在这个对象中传递过来进行更新操作。
+     * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了如UPDATE_SUCCESS、UPDATE_ERROR等枚举值，用于表示更新进货商品操作的成功或失败状态，
+    // 方便前端根据返回结果进行相应的处理或提示用户，比如提示用户更新成功或者告知更新失败的原因等。
+     */
+
+
+            // 调用inportService的updateById方法，将包含更新后进货商品信息的inportVo对象传递过去，服务层会根据对象中的主键信息（通常是进货记录的ID），
+            // 在数据库中找到对应的进货记录，并将其他属性值更新为inportVo对象中传入的新值，实现更新进货商品信息的功能，例如修改进货记录中的数量、价格等字段的值，
+            // 如果更新操作顺利完成则无异常抛出，若出现问题（比如找不到对应记录、更新数据违反约束等情况）则会抛出异常。
+
+            // 如果在更新进货商品信息的过程中出现异常，打印异常堆栈信息（便于开发人员排查问题根源），然后返回表示更新操作失败的ResultObj.UPDATE_ERROR结果对象给前端，
+            // 让前端知晓更新操作未成功，以便采取相应的提示或者其他处理措施，比如告知用户更新失败，可尝试再次操作等。
+
+
+    /**
+     * 删除进货商品
+     * @param id 要删除的进货商品记录的唯一标识符（通常是主键ID），由前端传入，通过这个ID来确定要从数据库中删除的具体进货记录。
+     * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了如DELETE_SUCCESS、DELETE_ERROR等枚举值，用于表示删除进货商品操作的成功或失败状态，
+     * 方便前端根据返回结果进行相应的处理或提示用户，比如提示用户删除成功或者告知删除失败的原因等。
+     */
+
+            // 调用inportService的removeById方法，传入要删除的进货记录的ID，服务层会根据这个ID在数据库中找到对应的进货记录并执行删除操作，
+            // 如果删除操作顺利完成则无异常抛出，若出现问题（比如存在关联数据、违反数据库约束等情况）则会抛出异常。
+
+            // 如果在删除进货商品的过程中出现异常，打印异常堆栈信息（便于开发人员排查问题根源），然后返回表示删除操作失败的ResultObj.DELETE_ERROR结果对象给前端，
+            // 让前端知晓删除操作未成功，以便采取相应的提示或者其他处理措施，比如告知用户删除失败，可尝试再次操作等。

src/main/java/com/yeqifu/bus/controller/OutportController.java

@@ -114,3 +114,101 @@ public class OutportController {
 
 }
 
+
+// OutportController类，使用了@RestController注解，表明这是一个Spring框架中的RESTful风格的控制器类，
+// 用于处理与商品退货（Outport）相关的HTTP请求，并将处理结果以JSON等格式返回给客户端（通常是前端页面），是连接前端与后端业务逻辑的重要环节。
+// 同时通过@RequestMapping("/outport")注解，为该控制器下的所有请求映射路径设置了一个公共的前缀"/outport"，方便对相关的API进行统一管理和区分。
+
+
+    // 使用@Autowired注解自动注入IOutportService接口的实现类对象，用于调用与商品退货相关的业务逻辑方法，
+    // 例如添加退货信息、分页查询退货记录、删除退货信息等操作，具体的业务实现是在对应的服务层接口实现类中完成的，这里只是进行调用触发相应逻辑。
+
+
+    // 同样通过@Autowired注解注入IProviderService接口的实现类对象，用于获取供应商相关的业务服务，
+    // 在查询商品退货信息时，会借助该服务根据供应商ID查询供应商详细信息，以便补充到退货记录中展示更完整的数据。
+
+    // 注入IGoodsService接口的实现类对象，用于获取商品相关的业务服务，在查询商品退货信息时，通过该服务依据商品ID查询商品详情（如名称、规格等），
+    // 然后将这些商品相关信息设置到退货记录中，使返回给前端的数据更加丰富全面，方便前端展示和业务操作。
+
+    /**
+     * 添加退货信息
+     * @param id 进货单ID，用于明确此次退货操作是针对哪一笔进货业务进行的，是关联到具体进货记录的关键标识，由前端传入。
+     * @param number 退货数量，指定了要退回商品的具体数量，这个数量信息对于后续更新库存、统计退货数据等业务操作至关重要，同样由前端传入。
+     * @param remark 备注，用于记录一些额外的关于此次退货的相关情况说明，比如退货原因（是商品质量问题、数量不符还是其他原因等）、特殊的退货协商结果等内容，也是由前端传入。
+     * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了诸如BACKINPORT_SUCCESS、BACKINPORT_ERROR等枚举值，用于明确表示添加退货信息操作的成功或失败状态，以便前端根据返回结果进行相应提示或处理。
+     */
+
+            // 调用outportService的addOutport方法，将前端传入的进货单ID、退货数量和备注信息传递过去，触发服务层的添加退货信息业务逻辑，
+            // 该逻辑可能涉及到更新库存、在数据库中插入退货记录、处理与财务等相关模块的数据交互等一系列复杂操作，如果操作顺利完成则无异常抛出，若过程中出现问题（比如数据库操作失败、业务规则校验不通过等）则会抛出异常。
+
+            // 如果在添加退货信息过程中出现异常，打印异常堆栈信息（方便开发人员排查问题根源），然后返回表示添加退货信息失败的ResultObj.BACKINPORT_ERROR结果对象给前端，
+            // 使得前端能够知晓操作未成功，进而进行相应的提示告知用户或者采取其他补救措施等。
+
+
+    /**
+     * 查询商品退货
+     * @param outportVo 这是一个封装了查询条件的对象，通常包含分页相关信息（如页码、每页显示数量）以及其他筛选条件（如供应商ID、商品ID、时间范围等），由前端传入，方便在后端统一处理各种查询需求。
+     * @return 返回一个DataGridView对象，该对象一般是项目中自定义用于封装数据展示相关信息的，这里面包含了查询到的商品退货记录的总数量以及具体的退货记录列表，方便前端进行分页展示和数据处理等操作。
+     */
+
+
+        // 创建一个IPage对象，用于实现分页功能，通过传入从outportVo对象中获取的当前页码（outportVo.getPage()）和每页显示记录数量（outportVo.getLimit()）来确定分页范围，
+        // 例如，当页码为2且每页显示数量为10时，表示要获取第2页，每页显示10条商品退货记录的那部分数据，方便对大量退货记录进行分页展示，提升前端展示和用户查看数据的体验。
+
+
+        // 创建一个QueryWrapper对象，用于构建查询条件，类似于构建SQL语句中的WHERE子句部分，方便灵活地添加各种筛选条件来精确查询符合要求的商品退货记录。
+
+
+        // 对供应商进行查询，如果outportVo对象中获取的供应商ID（outportVo.getProviderid()）不为空且不等于0，说明前端传入了供应商筛选条件，
+        // 则添加一个相等性查询条件，在数据库表中对应"providerid"字段，查找与传入的供应商ID相等的退货记录，以此实现按供应商筛选退货信息的功能。
+
+
+        // 对商品进行查询，同理，当outportVo对象中获取的商品ID（outportVo.getGoodsid()）不为空且不等于0时，表明前端传入了商品筛选条件，
+        // 就在数据库表的"goodsid"字段添加相等性查询条件，查找与传入商品ID匹配的退货记录，便于根据具体商品来查询其退货情况。
+
+
+        // 对时间进行查询要求大于开始时间小于结束时间，当outportVo对象中的开始时间（outportVo.getStartTime()）不为空时，添加一个大于等于（ge）的查询条件，
+        // 在数据库表的"outputtime"字段（推测是退货时间字段）上，筛选出退货时间大于等于传入的开始时间的退货记录；同样，当结束时间（outportVo.getEndTime()）不为空时，
+        // 添加一个小于等于（le）的查询条件，筛选出退货时间小于等于传入的结束时间的退货记录，这样就能获取到处于指定时间范围内的商品退货信息，方便按时间区间进行数据查询和统计分析等操作。
+
+
+        // 通过进货时间对商品进行排序，添加一个按照"outputtime"字段（退货时间）进行降序排序的条件，使得查询返回的退货记录按照退货时间从近到远的顺序排列，
+        // 这样在前端展示时，用户能先看到较新的退货记录，更符合一般的数据查看习惯，方便查看和分析近期的退货情况。
+
+        // 调用outportService的page方法，传入构建好的分页对象page和查询条件包装器queryWrapper，服务层会根据这些条件执行数据库查询操作，
+        // 获取符合条件的商品退货数据，并将数据填充到page对象中，例如设置page对象中的总记录数、当前页的记录列表等属性，最终返回填充好数据的page对象赋值给page1。
+
+
+        // 获取查询结果中当前页的退货记录列表，方便后续对每条记录进行补充相关信息的操作，比如添加供应商名称、商品名称和规格等，使返回给前端的数据更加完整详细。
+
+        // 遍历当前页查询到的每条商品退货记录，为每条记录补充供应商名称、商品名称和规格等信息，使其展示的数据更加丰富全面，方便前端展示和业务查看使用。
+
+            // 通过providerService的getById方法，根据当前退货记录中的供应商ID（ouport.getProviderid()）从数据库中查询对应的供应商详细信息，获取到一个Provider对象（如果存在的话）。
+
+
+                // 如果查询到了对应的供应商信息，将供应商的名称设置到当前退货记录（ouport）中，以便前端展示退货记录时能同时显示供应商名称，让数据更直观、完整。
+
+            // 通过goodsService的getById方法，依据当前退货记录中的商品ID（ouport.getGoodsid()）从数据库中查询对应的商品详细信息，获取到一个Goods对象（若存在的话）。
+
+                // 如果查询到了商品信息，将商品的名称设置到当前退货记录（ouport）中，方便前端展示退货记录时能呈现商品名称，使数据更具可读性。
+
+                // 同时将商品的规格信息也设置到当前退货记录（ouport）中，进一步丰富退货记录展示的数据内容，便于业务操作和查看详细情况。
+
+
+        // 创建一个DataGridView对象，将查询得到的商品退货记录的总数量（通过page1.getTotal()获取）以及当前页补充完整信息后的退货记录列表（page1.getRecords()）进行封装，
+        // 最终返回给前端，使得前端能够按照分页逻辑展示商品退货信息，并且展示的数据包含了丰富的关联信息（供应商名称、商品名称和规格等），满足业务查看和操作的需求。
+
+
+    /**
+     * 删除退货信息
+     * @param id 要删除的退货记录的唯一标识符（通常是主键ID），由前端传入，通过这个ID来确定要从数据库中删除的具体退货记录。
+     * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了如DELETE_SUCCESS、DELETE_ERROR等枚举值，用于表示删除退货信息操作的成功或失败状态，方便前端根据返回结果进行相应处理或提示用户。
+     */
+
+
+
+            // 调用outportService的removeById方法，传入要删除的退货记录的ID，服务层会根据这个ID在数据库中找到对应的退货记录并执行删除操作，
+            // 如果删除操作顺利完成则无异常抛出，若出现问题（比如存在关联数据、违反数据库约束等）则会抛出异常。
+
+            // 如果在删除退货信息过程中出现异常，打印异常堆栈信息（便于开发人员排查问题），然后返回表示删除操作失败的ResultObj.DELETE_ERROR结果对象给前端，
+            // 让前端知晓删除操作未成功，以便采取相应的提示或其他处理措施。

src/main/java/com/yeqifu/bus/controller/ProviderController.java

@@ -115,3 +115,90 @@ public class ProviderController {
 
 }
 
+// 假设所在类是一个Spring的RestController（通过 @RestController 注解标识，用于处理HTTP请求并返回JSON等格式的数据响应），用于处理与供应商（Provider）相关的各种业务请求。
+
+
+
+    // 注入一个实现了IService<Provider>接口的服务层对象（这里假设名为providerService），用于调用服务层提供的与供应商相关的业务逻辑方法，
+    // 虽然代码中没有显示注入的语句，但在实际的Spring项目中，通常会通过依赖注入的方式获取该服务对象，比如使用 @Autowired 注解等方式进行注入。
+
+    // 根据传入的供应商查询条件（封装在ProviderVo对象中），加载所有符合条件的供应商信息，并进行分页返回。
+
+        // 1. 声明一个分页page对象
+        // 创建一个IPage对象，用于实现分页功能，它接收当前页码（通过providerVo.getPage()获取，即从前端传入的页码信息）和每页显示的记录数量（通过providerVo.getLimit()获取）作为参数，
+        // 这样就确定了本次查询数据的分页范围，例如，当page为2且limit为10时，表示要获取第2页，每页显示10条供应商记录的那部分数据。
+
+
+        // 2. 声明一个queryWrapper
+        // 创建一个QueryWrapper对象，用于构建查询条件，它可以方便地通过链式调用的方式添加各种查询条件，类似于构建SQL语句中的WHERE子句部分，用于筛选符合特定条件的供应商记录。
+
+
+        // 根据供应商名称进行模糊查询，如果传入的供应商名称（通过providerVo.getProvidername()获取）不为空字符串（使用StringUtils.isNotBlank方法判断），
+        // 则添加一个模糊查询条件，在数据库表中对应"providername"字段进行模糊匹配（匹配包含传入名称的记录），方便根据名称查找相关的供应商。
+
+
+        // 根据联系人名称进行模糊查询，原理同上面的供应商名称查询，若传入的联系人名称（通过providerVo.getConnectionperson()获取）不为空，就在"connectionperson"字段上添加模糊查询条件，
+        // 以便筛选出符合联系人名称要求的供应商记录。
+
+
+        // 根据电话号码进行模糊查询，同样判断传入的电话号码（通过providerVo.getPhone()获取）是否不为空，若不为空，则在"phone"字段添加模糊查询条件，实现按电话号码查找供应商的功能。
+
+
+        // 调用服务层的page方法，传入构建好的分页对象page和查询条件包装器queryWrapper，服务层会根据这些条件执行数据库查询操作，获取符合条件的供应商数据，并将数据填充到page对象中，
+        // 例如设置page对象中的总记录数、当前页的记录列表等属性，以便后续返回分页数据。
+
+
+        // 创建一个DataGridView对象，用于将分页查询得到的结果（总记录数通过page.getTotal()获取，当前页的记录列表通过page.getRecords()获取）进行封装，
+        // 最终返回给前端，方便前端进行分页数据展示等操作，DataGridView对象的具体结构和作用取决于项目中的自定义，一般是将数据整理成适合前端接收和展示的格式。
+
+
+
+    /**
+     * 添加一个供应商
+     * @param providerVo 包含要添加的供应商信息的对象，通常是从前端传递过来，封装了供应商的各项属性值，比如名称、联系人、电话等信息。
+     * @return 返回一个ResultObj类型的结果对象，用于表示添加操作的成功或失败状态，ResultObj中定义了如ADD_SUCCESS、ADD_ERROR等枚举值来明确表示不同的结果情况。
+     */
+
+            // 调用服务层的save方法，将传入的包含供应商信息的providerVo对象传递给服务层，服务层会将这些信息保存到数据库中，实现添加供应商的功能，
+            // 例如将供应商的基本信息插入到对应的供应商表中，如果保存成功则无异常抛出，若保存过程中出现问题（如数据库连接异常、数据格式不符合要求等）则会抛出异常。
+
+            // 如果在保存供应商信息过程中出现异常，打印异常堆栈信息（方便开发人员排查问题），然后返回表示添加失败的ResultObj.ADD_ERROR结果对象给前端，
+            // 让前端知道添加操作没有成功，以便进行相应的提示或处理。
+
+
+    /**
+     * 修改一个供应商
+     * @param providerVo 包含要修改的供应商新信息的对象，从前端传入，里面的属性值是修改后的值，通过与数据库中已存在的供应商记录的主键等信息进行匹配来确定要修改的具体记录。
+     * @return 返回一个ResultObj类型的结果对象，用于表示修改操作的成功或失败状态，ResultObj中定义了如UPDATE_SUCCESS、UPDATE_ERROR等枚举值来明确表示不同的结果情况。
+     */
+
+            // 调用服务层的updateById方法，将传入的包含更新后供应商信息的providerVo对象传递给服务层，服务层会根据对象中的主键信息（通常是供应商的ID），
+            // 在数据库中找到对应的供应商记录，并将其他属性值更新为providerVo对象中传入的新值，实现修改供应商信息的功能，如果更新成功则无异常抛出，若出现问题（如找不到对应记录、更新数据违反约束等）则会抛出异常。
+
+            // 如果在更新供应商信息过程中出现异常，打印异常堆栈信息（方便开发人员排查问题），然后返回表示修改失败的ResultObj.UPDATE_ERROR结果对象给前端，
+            // 让前端知道修改操作没有成功，以便进行相应的提示或处理。
+
+
+    /**
+     * 删除一个供应商
+     * @param id 要删除的供应商的唯一标识符（通常是主键ID），由前端传入，通过这个ID来确定要从数据库中删除的具体供应商记录。
+     * @return 返回一个ResultObj类型的结果对象，用于表示删除操作的成功或失败状态，ResultObj中定义了如DELETE_SUCCESS、DELETE_ERROR等枚举值来明确表示不同的结果情况。
+     */
+
+
+    /**
+     * 加载所有可用的供应商
+     * @return 返回一个DataGridView对象，里面包含了所有可用的供应商信息列表，用于在前端展示所有当前处于可用状态的供应商情况，方便后续业务操作选择使用。
+     */
+
+
+
+        // 添加一个相等性查询条件，在数据库表中对应"available"字段，查询其值等于Constast.AVAILABLE_TRUE（这里Constast应该是项目中定义的一个常量类，AVAILABLE_TRUE表示可用状态的常量值）的供应商记录，
+        // 以此获取所有处于可用状态的供应商信息。
+
+
+        // 调用服务层的list方法，传入构建好的查询条件包装器queryWrapper，服务层会根据这个条件执行数据库查询操作，获取所有符合可用状态条件的供应商数据，并返回一个包含这些供应商对象的列表。
+
+
+        // 创建一个DataGridView对象，将查询得到的可用供应商列表进行封装，最终返回给前端，方便前端进行展示或者其他相关业务操作（比如在下拉框中展示可用供应商供用户选择等）。
+

src/main/java/com/yeqifu/bus/controller/SalesbackController.java

@@ -114,3 +114,103 @@ public class SalesbackController {
     
 }
 
+
+
+// SalesbackController类，使用了@RestController注解，表明它是Spring框架下用于构建RESTful API的控制器类，主要负责处理与商品销售退货（Salesback）相关的HTTP请求，
+// 并将处理结果以合适的格式（如JSON）返回给客户端（通常是前端应用），在整个项目的前后端交互中起着桥梁的作用。同时，通过@RequestMapping("/salesback")注解，
+// 为该控制器下所有的请求映射路径设置了公共前缀"/salesback"，便于对商品销售退货相关的接口进行统一管理和分类。
+
+    // 使用@Autowired注解自动注入ISalesbackService接口的实现类对象，通过这个服务对象，可以调用与商品销售退货相关的核心业务逻辑方法，
+    // 比如添加退货信息、分页查询销售退货记录以及删除销售退回信息等操作，具体的业务实现细节则在ISalesbackService接口对应的实现类中完成，这里只是进行调用触发相应的业务逻辑流程。
+
+
+    // 通过@Autowired注解注入ICustomerService接口的实现类对象，用于获取客户相关的业务服务。在查询商品销售退货信息时，借助该服务根据客户ID查询客户的详细信息，
+    // 以便将客户姓名等相关信息补充到销售退货记录中，使返回给前端的数据更加完整，方便前端展示和业务操作时能呈现更全面的客户相关情况。
+
+    // 同样使用@Autowired注解注入IGoodsService接口的实现类对象，用于获取商品相关的业务服务。在处理销售退货记录查询结果时，通过该服务依据商品ID查询商品详情（如商品名称、规格等），
+    // 然后将这些商品相关信息设置到销售退货记录中，进一步丰富返回给前端的数据内容，让前端能够展示更详细的商品相关信息，便于业务查看和分析销售退货情况。
+
+    /**
+     * 添加退货信息
+     * @param id 进货单ID，这里可能用于关联到对应的销售记录，以明确此次销售退货操作是针对哪一笔销售业务进行的，作为确定退货操作关联业务的关键标识，由前端传入该参数。
+     * @param number 退货数量，指定了此次销售退货中商品的具体数量，这个数量信息对于后续更新库存、统计退货数据以及涉及财务等相关业务操作都非常重要，同样由前端传入。
+     * @param remark 备注，用于记录一些额外的关于此次销售退货的相关情况说明，例如退货原因（是商品质量问题、客户不满意还是其他原因等）、特殊的退货协商结果等内容，由前端传入该参数。
+     * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了诸如BACKINPORT_SUCCESS、BACKINPORT_ERROR等枚举值，用于明确表示添加销售退货信息操作的成功或失败状态，
+     * 方便前端根据接收到的返回结果进行相应的提示操作或者后续处理，比如提示用户添加成功或者告知添加失败的原因等。
+     */
+
+
+            // 调用salesbackService的addSalesback方法，将前端传入的进货单ID、退货数量以及备注信息传递过去，以此触发服务层中处理添加销售退货信息的业务逻辑，
+            // 该逻辑可能涉及到调整库存（将退货商品重新入库）、在数据库中插入销售退货记录、更新与销售退货相关的财务数据以及其他关联业务模块的数据交互等一系列复杂操作，
+            // 如果整个操作过程顺利完成，不会抛出异常；若在执行过程中出现问题（比如数据库插入失败、业务规则校验不通过等情况），则会抛出异常。
+
+            // 如果在添加销售退货信息的过程中出现异常，通过打印异常堆栈信息（这有助于开发人员在排查问题时了解详细的异常发生位置和原因），
+            // 然后返回表示添加销售退货信息失败的ResultObj.BACKINPORT_ERROR结果对象给前端，使得前端能够知晓操作未成功，进而采取相应的提示告知用户或者其他补救措施等。
+
+
+    /**
+     * 查询商品销售退货
+     * @param salesbackVo 这是一个封装了查询条件的对象，通常包含分页相关信息（如页码、每页显示数量）以及其他筛选条件（如客户ID、商品ID、时间范围等），由前端传入，
+     * 方便后端统一处理各种不同的查询需求，根据这些条件从数据库中准确获取符合要求的商品销售退货记录。
+     * @return 返回一个DataGridView对象，该对象一般是项目中自定义用于封装数据展示相关信息的，其中包含了查询到的商品销售退货记录的总数量以及具体的退货记录列表，
+     * 方便前端进行分页展示以及对数据进行进一步的处理和分析等操作。
+     */
+
+        // 创建一个IPage对象，用于实现分页功能，通过传入从salesbackVo对象中获取的当前页码（salesbackVo.getPage()）和每页显示记录数量（salesbackVo.getLimit()）来确定分页范围，
+        // 例如，当页码为2且每页显示数量为10时，表示要获取第2页，每页显示10条商品销售退货记录的那部分数据，这样可以对大量的销售退货记录进行分页管理，提升前端展示效果以及用户查看数据的体验。
+
+
+        // 创建一个QueryWrapper对象，用于构建查询条件，它类似于构建SQL语句中的WHERE子句部分，能够灵活地添加各种筛选条件，从而精确地查询出符合特定要求的商品销售退货记录。
+
+
+        // 对客户进行查询，如果从salesbackVo对象中获取的客户ID（salesbackVo.getCustomerid()）不为空且不等于0，说明前端传入了客户筛选条件，
+        // 则添加一个相等性查询条件，在数据库表中对应"customerid"字段，查找与传入的客户ID相等的销售退货记录，以此实现按客户来筛选销售退货信息的功能，方便查看特定客户的销售退货情况。
+
+
+        // 对商品进行查询，同理，当salesbackVo对象中获取的商品ID（salesbackVo.getGoodsid()）不为空且不等于0时，表明前端传入了商品筛选条件，
+        // 就在数据库表的"goodsid"字段添加相等性查询条件，查找与传入商品ID匹配的销售退货记录，便于根据具体商品来查询其销售退货情况，满足不同业务场景下对商品销售退货数据的查询需求。
+
+        // 对时间进行查询要求大于开始时间小于结束时间，当salesbackVo对象中的开始时间（salesbackVo.getStartTime()）不为空时，添加一个大于等于（ge）的查询条件，
+        // 在数据库表的"salesbacktime"字段（推测是商品销售退货时间字段）上，筛选出销售退货时间大于等于传入的开始时间的销售退货记录；同样，当结束时间（salesbackVo.getEndTime()）不为空时，
+        // 添加一个小于等于（le）的查询条件，筛选出销售退货时间小于等于传入的结束时间的销售退货记录，这样就能获取到处于指定时间范围内的商品销售退货信息，方便按时间区间进行数据查询、统计分析等操作。
+
+
+        // 通过商品退货时间对商品进行排序，添加一个按照"salesbacktime"字段（商品销售退货时间）进行降序排序的条件，使得查询返回的销售退货记录按照退货时间从近到远的顺序排列，
+        // 这样在前端展示时，用户能先看到较新的销售退货记录，更符合一般的数据查看习惯，方便查看和分析近期的销售退货情况，有助于及时发现问题或者跟踪业务趋势。
+
+        // 调用salesbackService的page方法，传入构建好的分页对象page和查询条件包装器queryWrapper，服务层会根据这些条件执行数据库查询操作，
+        // 获取符合条件的商品销售退货数据，并将数据填充到page对象中，例如设置page对象中的总记录数、当前页的记录列表等属性，以便后续返回完整的分页数据信息。
+
+
+        // 获取查询结果中当前页的销售退货记录列表，方便后续对每条记录进行补充相关信息的操作，比如添加客户姓名、商品名称和规格等，使返回给前端的数据更加丰富详细，更具业务价值。
+
+
+        // 遍历当前页查询到的每条商品销售退货记录，为每条记录补充客户姓名、商品名称和规格等信息，使其展示的数据更加完整全面，方便前端展示以及业务查看和操作使用。
+
+            // 通过customerService的getById方法，根据当前销售退货记录中的客户ID（salesback.getCustomerid()）从数据库中查询对应的客户详细信息，获取到一个Customer对象（如果存在的话）。
+
+                // 如果查询到了对应的客户信息，将客户的姓名设置到当前销售退货记录（salesback）中，以便前端展示销售退货记录时能同时显示客户姓名，让数据更直观、完整，便于业务人员查看相关客户的退货情况。
+
+            // 通过goodsService的getById方法，依据当前销售退货记录中的商品ID（salesback.getGoodsid()）从数据库中查询对应的商品详细信息，获取到一个Goods对象（若存在的话）。
+
+                // 如果查询到了商品信息，将商品的名称设置到当前销售退货记录（salesback）中，方便前端展示销售退货记录时能呈现商品名称，使数据更具可读性，便于了解退货商品的具体情况。
+
+                // 同时将商品的规格信息也设置到当前销售退货记录（salesback）中，进一步丰富退货记录展示的数据内容，方便业务人员更详细地掌握退货商品的规格特点等信息。
+
+
+        // 创建一个DataGridView对象，将查询得到的商品销售退货记录的总数量（通过page.getTotal()获取）以及当前页补充完整信息后的销售退货记录列表（page.getRecords()）进行封装，
+        // 最终返回给前端，使得前端能够按照分页逻辑展示商品销售退货信息，并且展示的数据包含了丰富的关联信息（客户姓名、商品名称和规格等），满足业务查看和操作的实际需求。
+
+
+    /**
+     * 删除商品销售退回信息
+     * @param id 要删除的商品销售退回记录的唯一标识符（通常是主键ID），由前端传入，通过这个ID来确定要从数据库中删除的具体销售退回记录。
+     * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了如DELETE_SUCCESS、DELETE_ERROR等枚举值，用于表示删除商品销售退回信息操作的成功或失败状态，
+     * 方便前端根据返回结果进行相应的处理或提示用户，比如提示用户删除成功或者告知删除失败的原因等。
+     */
+
+            // 调用salesbackService的removeById方法，传入要删除的销售退回记录的ID，服务层会根据这个ID在数据库中找到对应的销售退回记录并执行删除操作，
+            // 如果删除操作顺利完成则无异常抛出，若出现问题（比如存在关联数据、违反数据库约束等情况）则会抛出异常。
+
+            // 如果在删除商品销售退回信息的过程中出现异常，打印异常堆栈信息（便于开发人员排查问题根源），然后返回表示删除操作失败的ResultObj.DELETE_ERROR结果对象给前端，
+            // 让前端知晓删除操作未成功，以便采取相应的提示或者其他处理措施，比如告知用户删除失败，可尝试再次操作等。

src/main/java/com/yeqifu/bus/entity/Customer.java

@@ -54,3 +54,63 @@ public class Customer implements Serializable {
 
 
 }
+/*
+ * Customer类是一个用于对客户实体进行建模的Java类，实现了Serializable接口，这使得该类的实例对象能够方便地进行序列化和反序列化操作，
+ * 比如在将客户数据保存到文件系统、通过网络传输给其他系统或者从数据库中读取并还原对象状态等场景中都会用到序列化功能，以此保证数据的完整性和可恢复性。
+ *
+ * 该类包含了一系列用于描述客户各方面信息的成员变量，这些变量共同构成了完整的客户信息画像，方便在业务系统中对客户进行管理、查询以及各种业务操作。
+ */
+
+
+    // 序列化版本号，在Java的序列化机制中起着重要作用，它用于验证在不同版本的类结构变化时，反序列化操作能否正确进行，这里初始化为1L，
+    // 意味着当前版本的类结构在序列化相关操作下的一个初始标识，后续若类结构发生变更（如添加、删除成员变量等），可能需要相应地更新此版本号。
+
+
+    // 通过@TableId注解指定该属性为对应数据库表中的主键字段，名为"id"，并且采用IdType.AUTO的主键生成策略，
+    // 也就是在向数据库插入新的客户记录时，数据库会自动为其分配一个唯一的ID值，这个ID作为客户在整个业务系统中的唯一标识符，
+    // 可用于精准地定位、查询以及关联与该客户相关的所有业务数据，比如订单数据、交易记录等。
+
+
+    // 客户姓名，是识别客户个体的关键信息之一，在业务系统的各种界面展示、报表生成以及客户沟通等场景中都会频繁使用，
+    // 例如客服人员根据客户姓名查找对应的客户记录，以便提供针对性的服务。
+
+
+    // 邮政编码，与客户的地址信息紧密相关，有助于在物流配送、地址验证等业务环节准确地定位客户所在的地理区域，
+    // 像电商平台根据邮编确定包裹的大致投递范围，提高配送效率。
+
+
+    // 客户的详细地址，详细描述了客户所处的具体位置，是开展线下业务活动（如上门拜访、售后服务等）以及邮寄物品等操作的重要依据，
+    // 其格式通常包含省、市、区、街道、门牌号等具体信息，确保能准确找到客户所在地。
+
+
+    // 固定电话号码，虽然随着移动通讯的发展使用频率相对降低，但在部分企业客户或者特定业务场景中仍可能是重要的联系方式，
+    // 例如一些传统行业的企业之间通过固定电话进行业务洽谈、客服咨询等沟通活动。
+
+    // 联系人姓名，在涉及到企业客户或者有多个联系人的情况下，用于明确与业务系统对接的具体人员，
+    // 比如一家公司有多个采购人员，通过指定联系人姓名可以精准地找到对应的业务对接人，方便订单处理、商务沟通等操作。
+
+
+    // 手机号码，作为现代社会最常用的通信方式之一，是与客户进行即时沟通、发送通知（如验证码、营销信息等）的重要途径，
+    // 几乎所有的线上业务活动（如APP登录验证、会员服务通知等）都会依赖手机号码来与客户建立联系。
+
+    // 开户银行名称，反映了客户的资金账户所属的金融机构，在涉及到财务结算、转账汇款等资金相关业务操作时，
+    // 明确开户银行是确保资金准确、安全流转的关键信息，比如企业向客户付款时需要知道对方的开户银行才能顺利完成转账。
+
+
+    // 银行账号，是客户在其开户银行的唯一资金账户标识，在各种资金往来业务（如收款、付款、对账等）中起着核心作用，
+    // 任何一笔涉及该客户的资金交易都需要通过这个账号来准确地进行资金划转和记录。
+
+
+    // 电子邮箱地址，是互联网时代重要的信息交流工具，用于接收各类电子文档（如合同、账单等）、业务通知以及进行商务邮件往来等，
+    // 例如企业通过电子邮件向客户发送月度账单、营销活动邮件等，以实现高效的业务沟通。
+
+
+    // 传真号码，尽管在当今数字化办公环境下使用越来越少，但在某些特定行业（如外贸、金融等部分传统业务领域）仍可能保留一定的使用场景，
+    // 比如外贸企业之间通过传真传递重要的商务文件、合同等，作为一种具有法律效力的书面沟通方式。
+
+
+    // 可用状态标识，用于标记该客户在业务系统中的可用性，例如在系统中可以规定1表示客户处于正常可用状态，能够进行各种业务操作，
+    // 而0则表示客户可能因某些原因（如欠费、违规等）处于不可用状态，无法开展正常业务，通过这个标识可以方便地对客户进行筛选、管控等操作。
+
+
+

src/main/java/com/yeqifu/bus/entity/Goods.java

@@ -25,21 +25,36 @@ import java.io.Serializable;
 @TableName("bus_goods")
 @ToString
 public class Goods implements Serializable {
+    // 序列化版本号，在Java的序列化机制中起着关键作用，它用于验证在不同版本的类结构发生变化时，反序列化操作能否正确进行，
+    // 这里初始化为1L，意味着当前版本的类结构在序列化相关操作下的一个初始标识，后续若类结构发生变更（如添加、删除成员变量等），可能需要相应地更新此版本号，
+    // 以避免反序列化失败的问题，确保数据的兼容性和稳定性
 
     private static final long serialVersionUID=1L;
+    // 通过@TableId注解指定该属性为对应数据库表中的主键字段，名为"id"，并且采用IdType.AUTO的主键生成策略，
+    // 也就是在向数据库插入新的商品记录时，数据库会自动为其分配一个唯一的ID值，这个ID作为商品在整个业务系统中的唯一标识符，
+    // 可用于精准地定位、查询以及关联与该商品相关的所有业务数据，比如销售记录、库存变动记录等，是整个商品数据管理的核心标识之一。
 
     @TableId(value = "id", type = IdType.AUTO)
     private Integer id;
+    // 商品名称，是识别商品个体的最直观关键信息，在电商平台的前端页面展示、用户搜索商品、后台商品管理等众多业务场景中都会频繁使用，
+    // 例如用户通过输入商品名称在搜索栏查找心仪的商品，商家在后台管理系统中根据商品名称进行商品信息的编辑、上下架等操作
 
     private String goodsname;
 
     private String produceplace;
+    // 商品的产地，这一信息在很多业务场景中都有重要意义，比如对于一些具有地域特色的商品（如某地的特产茶叶、水果等），产地信息可以作为商品品质、特色的一种标识，
+    // 同时在质量追溯、进出口贸易（涉及产地证明等文件）等环节中，产地信息也是不可或缺的，有助于确保商品来源的合法性和质量的可靠性
 
     private String size;
 
     private String goodspackage;
+    // 商品的规格尺寸，其具体内容根据商品类型的不同而各异，像服装类商品的尺寸关乎穿着是否合身，电子产品的尺寸可能影响其便携性和使用场景，
+    // 在商品详情页展示、用户筛选商品（按尺寸范围选择合适的商品等）以及库存管理（不同尺寸可能分开统计库存等）等业务操作中，规格尺寸都是重要的参考依据。
 
     private String productcode;
+    // 商品的包装信息，它涵盖了包装的形式（如盒装、袋装、瓶装等）、包装材料（如纸质、塑料、玻璃等）等方面，
+    // 在商品的运输过程中，合适的包装能保护商品不受损坏；在存储时，包装形式影响仓储空间的利用；在销售展示环节，精美的包装也能吸引消费者的目光，
+    // 所以包装信息对于商品的整个生命周期管理都有着不可忽视的作用。
 
     private String promitcode;
 
@@ -56,9 +71,19 @@ public class Goods implements Serializable {
     private Integer available;
 
     private Integer providerid;
+    // 供应商的ID，它建立了商品与供应商之间的关联关系，在采购管理、供应链溯源等业务场景中有着重要作用，
 
     @TableField(exist = false)
     private String providername;
+    // 使用@TableField注解且设置exist = false，表示该属性在数据库表中不存在对应的字段，但在Java类中用于临时存储或业务逻辑处理相关的数据
 
 
 }
+/*
+ * Goods类是一个用于对商品实体进行建模的Java类，实现了Serializable接口，这使得该类的实例对象能够方便地进行序列化和反序列化操作，
+ * 例如在电商系统中，商品数据可能需要通过网络传输到不同的服务器端进行处理（如分布式库存管理系统、订单处理系统等），或者将商品信息持久化存储到数据库中，
+ * 序列化功能就可以保证数据在这些过程中的完整性和可恢复性，确保各个环节能正确地使用商品数据。
+ *
+ * 该类运用了多个来自相关框架（如MyBatis-Plus等常用于Java持久化开发的框架）的注解来配置与数据库表的映射关系以及类自身的一些行为特性。
+ * 同时，它包含了众多用于描述商品各方面详细信息的成员变量，这些变量从不同维度刻画了商品的全貌，便于在业务系统中对商品进行全方位的管理、展示以及各种业务操作。
+ */

src/main/java/com/yeqifu/bus/entity/Outport.java

@@ -65,3 +65,54 @@ public class Outport implements Serializable {
     private String size;
 
 }
+// 以下代码片段可能是一个Java类中的成员变量声明部分，假设这个类用于表示某种进货相关的业务实体（比如进货记录等），通过这些变量来承载进货业务中涉及的各项信息。
+
+    // serialVersionUID用于控制Java对象的序列化版本，在对象进行序列化和反序列化操作时，通过这个版本号来确保兼容性。
+// 当类的结构发生变化（如新增、删除成员变量等情况）时，如果没有正确处理这个版本号，可能会导致反序列化失败。这里将其初始化为1L，表示当前的初始版本。
+
+
+    // @TableId注解用于标记该属性为对应数据库表的主键，通过设置value = "id"表明在数据库表中对应的字段名为"id"，
+// 而type = IdType.AUTO指定了主键的生成策略为自动增长，意味着在向数据库插入新记录时，数据库会自动为该字段分配一个唯一的值。
+// 此id属性通常作为该业务实体在整个系统中的唯一标识符，方便进行数据的查询、更新、删除等操作，例如精准定位某条进货记录。
+
+    // paytype用于存储支付类型信息，比如可以是"现金"、"转账"、"微信支付"、"支付宝支付"等具体的支付方式，以字符串形式记录，便于在业务中了解进货时采用的付款手段。
+
+
+    // inporttime用于记录进货的时间，其类型为Date，能够精确地保存具体的年月日时分秒等时间信息，对于后续查询特定时间段内的进货情况、统计进货频率等业务操作很有帮助。
+
+
+    // operateperson用于存储操作进货业务的人员姓名，明确是哪位工作人员进行了此次进货操作，方便进行业务责任追溯以及人员绩效统计等相关工作。
+
+
+    // number用于记录进货的数量，以整数形式表示，例如进货了多少件商品等，在库存管理、成本核算等业务环节中，这个数量是重要的基础数据。
+
+
+    // remark是备注信息字段，类型为字符串，通常用于记录一些额外的、需要说明的关于此次进货的相关情况，比如特殊的进货要求、商品质量备注等内容。
+
+    // inportprice用于存储进货价格，以Double类型来精确表示价格数值（可以包含小数部分，比如商品单价为12.5元等情况），
+// 它是计算进货成本、利润等财务相关数据的关键要素，在财务核算、价格分析等业务场景中起着重要作用。
+
+
+    // providerid用于存储供应商的唯一标识符，通过这个ID可以关联到对应的供应商信息，比如查询供应商的详细资料、联系信息等，建立起进货业务与供应商之间的关联关系。
+
+
+    // goodsid用于存储商品的唯一标识符，同样可以凭借这个ID去关联商品的详细信息，例如商品的具体规格、描述等内容，确定此次进货对应的具体商品是哪一种。
+
+    /**
+     * 供应商姓名
+     * 以下使用@TableField注解并设置exist = false，表示该属性在数据库表中并不存在对应的实际字段，
+     * 它可能是在业务逻辑处理过程中，为了方便使用而临时存储供应商姓名信息的变量，例如在展示进货记录详情时，无需再次查询数据库获取供应商名称，直接使用这个变量即可，提高效率。
+     */
+
+    /**
+     * 商品名称
+     * 与providername类似，通过@TableField(exist = false)注解表明该属性在数据库表中无对应字段，
+     * 它是用于在业务操作中临时存放商品名称信息的，方便在展示进货记录、进行业务分析等场景下，不用额外去查询关联表就能直接获取商品名称，增强代码执行的便捷性。
+     */
+
+
+    /**
+     * 商品规格
+     * 同样使用@TableField(exist = false)注解，说明此属性在数据库表中不存在实际字段，它主要是为了在业务处理时，
+     * 能够便捷地获取和使用商品的规格信息（比如衣服的尺码、电子产品的尺寸参数等），避免频繁与数据库交互获取相关数据，提升业务逻辑执行的效率。
+     */

src/main/java/com/yeqifu/bus/entity/Provider.java

@@ -54,3 +54,64 @@ public class Provider implements Serializable {
 
 
 }
+// Outport类，实现了Serializable接口，意味着该类的对象可以被序列化和反序列化，常用于数据传输（比如网络传输）、持久化存储（如保存到文件或数据库等场景）等情况，
+// 确保对象的状态能够完整地保存和恢复，以满足不同业务环节对数据处理的需求，在这里可能用于记录商品出货相关的业务信息。
+
+
+
+    // serialVersionUID是用于控制Java对象序列化版本的标识符，在对象进行序列化与反序列化操作时，会依据这个版本号来判断类结构是否匹配，确保兼容性。
+    // 当类的结构发生变化（例如添加、删除成员变量，修改成员变量类型等）时，如果不妥善处理这个版本号，可能导致反序列化失败，这里初始化为1L，表示当前类的初始序列化版本。
+
+
+    // @TableId注解用于标识该属性为对应数据库表的主键，通过指定value = "id"明确了在数据库表中对应的字段名为"id"，
+    // 并且设置type = IdType.AUTO来确定主键的生成策略为自动增长，也就是在向数据库插入新记录时，数据库会自动为该字段分配一个唯一的整数值，
+    // 这个id属性作为每条出货记录在系统中的唯一标识，方便后续对特定出货记录进行查询、更新、删除等数据库操作，例如准确查找某次出货的详细信息。
+
+    // providerid用于存储供应商的唯一标识符，通过这个整数值可以关联到具体的供应商信息，比如在业务系统中通过该ID查找供应商的详细资料（名称、联系方式、地址等），
+    // 它建立了出货业务与供应商之间的关联关系，在统计与某个供应商的出货情况、进行供应商相关业务分析等场景中有着重要作用。
+
+
+    // paytype用于记录出货时采用的支付类型，其类型为字符串，例如可以是"现金"、"转账"、"电子支付（如微信、支付宝等）"等具体的支付方式，方便在业务流程中了解此次出货对应的收款方式。
+
+
+    // outputtime用于保存出货的时间，类型为Date，能够精确记录具体的年月日时分秒等时间信息，这对于查询特定时间段内的出货量、分析出货频率等业务操作提供了准确的时间依据。
+
+
+    // operateperson用于存放执行此次出货操作的人员姓名，以字符串形式呈现，便于进行业务操作的责任追溯，比如出现问题时能快速定位到是哪位工作人员进行的出货操作，
+    // 同时也可用于人员绩效统计等与人员相关的业务管理工作。
+
+
+    // outportprice用于存储出货价格，以Double类型表示，能够精确地记录价格数值（包含小数部分，如商品单价为12.5元等情况），
+    // 它是计算出货业务收入、利润等财务相关数据的关键要素，在财务核算、价格分析等业务场景中扮演着重要角色。
+
+
+    // number用于记录出货的商品数量，以整数形式表示，例如出货了多少件商品等，在库存管理（根据出货数量更新库存）、销售统计等业务环节中，这个数量是不可或缺的基础数据。
+
+
+    // remark是备注信息字段，类型为字符串，主要用于记录一些额外的、需要说明的关于此次出货的相关情况，比如特殊的出货要求、商品质量备注、客户特殊需求等内容，
+    // 方便后续查看出货记录时能更全面地了解当时的业务详情。
+
+
+    // goodsid用于存储商品的唯一标识符，凭借这个ID可以关联到对应的商品详细信息，例如商品的具体规格、描述、库存情况等，确定此次出货对应的具体商品是哪一种，
+    // 在商品管理、库存管理与出货业务的关联操作中起着重要的纽带作用。
+
+
+    /**
+     * 供应商姓名
+     * 使用@TableField(exist = false)注解表明该属性在数据库表中不存在对应的实际字段，它是在业务逻辑处理过程中，
+     * 为了方便使用而临时存储供应商姓名信息的变量，例如在展示出货记录详情时，无需再次查询数据库获取供应商名称，直接使用这个变量即可，提高业务操作的便捷性和效率。
+     */
+
+
+    /**
+     * 商品名称
+     * 与providername类似，通过@TableField(exist = false)注解说明该属性在数据库表中没有对应的字段，
+     * 它是用于在业务操作中临时存放商品名称信息的，方便在展示出货记录、进行业务分析等场景下，不用额外去查询关联表就能直接获取商品名称，优化业务逻辑执行的效率。
+     */
+
+    /**
+     * 商品规格
+     * 同样借助@TableField(exist = false)注解表示此属性在数据库表中不存在实际字段，它的主要作用是在业务处理时，
+     * 能够便捷地获取和使用商品的规格信息（比如衣服的尺码、电子产品的尺寸参数等），避免频繁与数据库交互获取相关数据，提升业务处理的效率和便捷性。
+     */
+

src/main/java/com/yeqifu/bus/entity/Sales.java

@@ -64,4 +64,67 @@ public class Sales implements Serializable {
     @TableField(exist = false)
     private String size;
 
-}
+}// Sales类，用于对销售业务相关的数据进行建模，实现了Serializable接口，这使得该类的对象能够进行序列化和反序列化操作，
+// 方便在诸如网络传输（例如将销售数据发送到远程服务器进行统计分析等）、持久化存储（把销售记录保存到数据库或者文件中）等场景下使用，确保销售数据的完整性和可复用性。
+
+// 使用了多个来自相关框架（如MyBatis-Plus等常用于Java持久化开发的框架）的注解来配置与数据库表的映射关系以及类自身的一些行为特性。
+
+
+
+    // 序列化版本号，在Java的序列化机制中起着关键作用，用于确保在不同版本的类结构发生变化时，反序列化操作能够正确进行。
+    // 这里初始化为1L，表示当前版本的类结构在序列化相关操作下的一个初始标识，后续若类结构发生变更（如添加、删除成员变量等），可能需要相应地更新此版本号，
+    // 以避免反序列化失败的问题，保证数据的兼容性和稳定性。
+
+
+    // @TableId注解用于标记该属性为对应数据库表的主键，通过指定value = "id"表明在数据库表中对应的字段名为"id"，
+    // 同时设置type = IdType.AUTO来定义主键的生成策略为自动增长，即当向数据库插入新的销售记录时，数据库会自动为该字段分配一个唯一的整数值，
+    // 这个id属性作为每条销售记录在整个业务系统中的唯一标识符，方便后续对特定销售记录进行查询、更新、删除等数据库操作，例如精准查询某一笔销售业务的详细情况。
+
+
+    // customerid用于存储客户的唯一标识符，通过这个整数值可以关联到对应的客户信息，比如在业务系统中通过该ID查找客户的详细资料（客户名称、联系方式、地址等），
+    // 它建立了销售业务与客户之间的关联关系，在统计与某个客户的销售情况、进行客户关系管理、分析客户购买行为等业务场景中有着重要作用。
+
+
+    // paytype用于记录销售业务中采用的支付类型，其类型为字符串，例如可以是"现金"、"转账"、"微信支付"、"支付宝支付"等具体的支付方式，
+    // 方便在业务流程中了解此次销售对应的收款方式，对于财务统计、支付方式分析等业务操作提供了必要的信息。
+
+    // salestime用于保存销售发生的时间，类型为Date，能够精确记录具体的年月日时分秒等时间信息，这对于按时间维度查询销售数据（如查询某一天、某一个月的销售额）、
+    // 分析销售趋势（不同时间段内销售情况的变化）等业务操作提供了准确的时间依据。
+
+
+    // operateperson用于存放执行此次销售操作的人员姓名，以字符串形式呈现，便于进行业务操作的责任追溯，比如出现售后问题时能快速定位到是哪位工作人员进行的销售操作，
+    // 同时也可用于人员绩效统计等与人员相关的业务管理工作。
+
+    // number用于记录销售的商品数量，以整数形式表示，例如销售了多少件商品等，在库存管理（根据销售数量更新库存）、销售统计（计算销售额、销售量等）等业务环节中，这个数量是不可或缺的基础数据。
+
+
+    // remark是备注信息字段，类型为字符串，主要用于记录一些额外的、需要说明的关于此次销售的相关情况，比如客户的特殊要求、商品的特殊情况、促销活动备注等内容，
+    // 方便后续查看销售记录时能更全面地了解当时的业务详情。
+
+
+    // saleprice用于存储销售价格，以Double类型表示，能够精确地记录价格数值（包含小数部分，如商品单价为12.5元等情况），
+    // 它是计算销售额、利润等财务相关数据的关键要素，在财务核算、价格分析等业务场景中扮演着重要角色。
+
+
+    // goodsid用于存储商品的唯一标识符，凭借这个ID可以关联到对应的商品详细信息，例如商品的具体规格、描述、库存情况等，确定此次销售对应的具体商品是哪一种，
+    // 在商品管理、库存管理与销售业务的关联操作中起着重要的纽带作用。
+
+    /**
+     * 客户名称
+     * 使用@TableField(exist = false)注解表明该属性在数据库表中不存在对应的实际字段，它是在业务逻辑处理过程中，
+     * 为了方便使用而临时存储客户名称信息的变量，例如在展示销售记录详情时，无需再次查询数据库获取客户名称，直接使用这个变量即可，提高业务操作的便捷性和效率。
+     */
+
+
+    /**
+     * 商品名称
+     * 与customername类似，通过@TableField(exist = false)注解说明该属性在数据库表中没有对应的字段，
+     * 它是用于在业务操作中临时存放商品名称信息的，方便在展示销售记录、进行业务分析等场景下，不用额外去查询关联表就能直接获取商品名称，优化业务逻辑执行的效率。
+     */
+
+    /**
+     * 商品规格
+     * 同样借助@TableField(exist = false)注解表示此属性在数据库表中不存在实际字段，它的主要作用是在业务处理时，
+     * 能够便捷地获取和使用商品的规格信息（比如衣服的尺码、电子产品的尺寸参数等），避免频繁与数据库交互获取相关数据，提升业务处理的效率和便捷性。
+     */
+

src/main/java/com/yeqifu/bus/entity/Salesback.java

@@ -65,3 +65,69 @@ public class Salesback implements Serializable {
     private String size;
 
 }
+// Salesback类，主要用于对销售退货业务相关的数据进行建模和封装，实现了Serializable接口，这使得该类的对象能够支持序列化与反序列化操作，
+// 便于在诸如将退货数据传输到其他系统（例如与财务系统对接传递退货金额等信息）、持久化存储退货记录（保存到数据库以便后续查询和统计分析）等场景下使用，
+// 确保退货业务数据在不同环节的完整性和可用性。
+
+// 同时，这个类使用了多个来自常用开发框架（如MyBatis-Plus等）的注解来配置其与数据库表的映射关系以及定义类自身的一些便捷操作特性。
+
+
+
+    // 序列化版本号，在Java的序列化机制里起着至关重要的作用，用于保障在类结构随项目发展出现变化（例如后续添加、删除成员变量或者修改成员变量类型等情况）时，
+    // 反序列化操作依然能够正确执行，避免因版本不一致而导致的数据读取失败问题。此处初始化为1L，代表当前类结构在序列化方面的初始标识，后续若有变更需谨慎处理该版本号。
+
+
+    // @TableId注解用于明确指定该属性为对应数据库表（"bus_salesback"表）的主键，通过设定value = "id"表明在数据库表中对应的字段名为"id"，
+    // 并且采用type = IdType.AUTO的主键生成策略，意味着每当向数据库插入一条新的销售退货记录时，数据库会自动为这个"id"字段分配一个唯一的整数值，
+    // 该"id"属性作为每条销售退货记录在整个业务系统中的唯一标识符，方便后续针对特定退货记录进行精准查询、更新、删除等数据库操作，例如查找某一次具体退货业务的详细情况。
+
+    // customerid用于存储进行退货操作的客户的唯一标识符，借助这个整数值，业务系统可以关联到对应的客户详细信息（如客户姓名、联系方式、地址以及过往购买记录等），
+    // 它在建立销售退货业务与客户之间的关联关系方面起着关键作用，有助于统计特定客户的退货情况、分析客户退货行为、进行客户关系维护等业务场景的操作。
+
+    // paytype用于记录此次销售退货业务中所采用的支付退款方式，其类型为字符串，例如可能是"现金退款"、"原支付渠道退回（如原路返回微信支付、支付宝支付的款项等）"、"转账退款"等具体的支付类型描述，
+    // 该信息对于财务处理退货资金流向、核对退款方式以及分析不同支付退款方式的使用频率等业务操作有着重要意义。
+
+    // salesbacktime用于保存销售退货发生的具体时间，类型为Date，能够精确到年月日时分秒等时间细节，这为按照时间维度查询和统计退货数据（比如查询某一天、某一个月内的退货量、退货金额等）、
+    // 分析退货趋势（不同时间段内退货情况的变化规律）等业务操作提供了准确可靠的时间依据。
+
+
+    // salebackprice用于存储此次销售退货的价格，以Double类型来表示，能够精确地记录包含小数部分的价格数值（例如商品单价为12.5元的退货情况等），
+    // 它是计算退货金额、统计退货业务对财务影响（如退款总额、退货造成的利润变动等）等财务相关数据的核心要素，在财务核算、退货业务分析等场景中扮演着重要角色。
+
+
+    // operateperson用于存放执行此次销售退货操作的人员姓名，以字符串形式呈现，便于在业务流程中进行责任追溯，比如当出现退货纠纷或者需要核对退货操作细节时，
+    // 能够快速定位到是哪位工作人员负责的此次退货业务，同时也有助于进行人员绩效评估（考虑退货业务处理情况等因素）等与人员相关的业务管理工作。
+
+    // number用于记录退货的商品数量，以整数形式表示，例如退货了多少件商品等，在库存管理（根据退货数量更新库存数量，将退货商品重新入库等）、退货统计（计算退货量、分析不同商品的退货率等）等业务环节中，
+    // 该数量是必不可少的基础数据。
+
+
+    // remark是备注信息字段，类型为字符串，主要用于记录一些额外的、需要对此次销售退货业务进行说明的相关情况，比如退货原因（商品质量问题、客户不满意等）、
+
+
+
+    // goodsid用于存储退货商品的唯一标识符，通过这个ID可以关联到对应的商品详细信息，例如商品的具体名称、规格、库存情况以及商品的其他属性等，
+    // 它在将销售退货业务与商品管理相关环节进行关联操作中起到了重要的纽带作用，有助于准确处理退货商品的后续事宜（如重新入库、质量检查等）。
+
+
+    /**
+     * 客户姓名
+     * 使用@TableField(exist = false)注解表明该属性在数据库表（"bus_salesback"表）中不存在对应的实际字段，它是在业务逻辑处理过程中，
+     * 为了方便使用而临时存储客户姓名信息的变量，例如在展示销售退货记录详情时，无需再次查询数据库获取客户姓名，直接使用这个变量即可，提高业务操作的便捷性和效率，
+     * 避免了额外的数据库查询操作，优化了业务逻辑执行的性能。
+     */
+
+    /**
+     * 商品名称
+     * 与customername类似，通过@TableField(exist = false)注解说明该属性在数据库表中没有对应的字段，
+     * 它是用于在业务操作中临时存放商品名称信息的，方便在展示销售退货记录、进行业务分析等场景下，不用额外去查询关联表就能直接获取商品名称，
+     * 使得业务逻辑处理更加高效便捷，提升了整体业务操作的流畅性。
+     */
+
+
+    /**
+     * 商品规格
+     * 同样借助@TableField(exist = false)注解表示此属性在数据库表中不存在实际字段，它的主要作用是在业务处理时，
+     * 能够便捷地获取和使用商品的规格信息（比如衣服的尺码、电子产品的尺寸参数等），避免频繁与数据库交互获取相关数据，提高业务处理的效率，
+     * 尤其在需要快速查看退货商品具体规格以便进行后续处理（如检查商品完整性是否符合规格要求等）的场景中很有帮助。
+     */

src/main/java/com/yeqifu/bus/mapper/CustomerMapper.java

@@ -14,3 +14,12 @@ import com.baomidou.mybatisplus.core.mapper.BaseMapper;
 public interface CustomerMapper extends BaseMapper<Customer> {
 
 }
+/*
+ * 此为CustomerMapper接口，在基于常见的Java持久化框架（如MyBatis或MyBatis-Plus等）的项目架构中有着重要作用。
+ * 它继承自BaseMapper<Customer>，这里的BaseMapper是框架提供的一个基础的映射器接口，其内部已经封装了一系列针对指定实体类型（此处为Customer类型）的标准化数据库操作模板方法。
+ * 例如，通过继承BaseMapper，CustomerMapper会自动获得诸如selectById（根据ID查询客户记录）、insert（插入新的客户记录）、updateById（根据ID更新客户记录）、deleteById（根据ID删除客户记录）等基础的数据库操作方法，
+ * 这些方法极大地简化了开发人员编写与客户数据持久化相关的SQL语句及数据库交互逻辑的工作量。
+ * 而且，开发人员可以根据具体业务场景下客户数据管理的特殊需求，在这个CustomerMapper接口中进一步扩展自定义的数据库操作方法，
+ * 比如可能需要根据客户的某些特定属性进行复杂查询、关联查询等操作，就可以在这里额外定义对应的方法签名，然后在对应的XML映射文件（如果使用MyBatis的话）或者通过注解（如MyBatis-Plus的相关注解）来实现具体的SQL逻辑，
+ * 以此来完善整个客户数据持久化层面的功能，更好地服务于上层的业务逻辑层对客户数据的各种操作需求。
+ */

src/main/java/com/yeqifu/bus/mapper/GoodsMapper.java

@@ -58,3 +58,47 @@ public interface GoodsMapper extends BaseMapper<Goods> {
      */
     List<Goods> loadAllWarning();
 }
+
+
+// GoodsMapper接口，它继承自BaseMapper<Goods>，这意味着它可以复用MyBatis-Plus框架提供的基础的数据库操作方法（如常见的增删改查等操作），
+// 同时针对商品（Goods）相关的特定业务逻辑，定义了一些额外的数据库操作方法，用于与数据库进行交互，实现更贴合业务需求的持久化功能。
+// 该接口对应的实现类（通常由MyBatis-Plus框架自动生成或者开发人员手动实现）会具体负责将这些方法映射为相应的SQL语句，并执行与数据库的实际交互操作。
+// 接口文档注释中的信息“InnoDB free: 9216 kB; (`providerid`) REFER `warehouse/bus_provider`(`id`)”可能是关于数据库存储引擎以及表关联相关的一些提示信息，
+// 例如表明使用的是InnoDB存储引擎且有外键关联（这里是`providerid`关联到`warehouse/bus_provider`表的`id`字段），不过具体要结合实际数据库表结构来深入理解其含义。
+
+
+
+    // 根据商品id删除商品销售信息
+    // 此方法用于从数据库中删除与指定商品相关的销售信息，通过传入的参数id1（使用@Param注解将其命名为"goodsid"，方便在对应的SQL语句中引用这个参数），
+    // 在数据库的商品销售相关表（具体表名要根据实际数据库设计确定）中，依据商品的唯一标识符（id）找到对应的销售记录并执行删除操作，
+    // 以确保数据的一致性，例如当商品被删除或者相关业务逻辑需要清理其销售记录时调用该方法。
+
+
+    // 根据商品id删除商品销售退货信息
+    // 功能与deleteSaleByGoodsId类似，不过是针对商品销售退货相关的数据进行删除操作，传入的参数id1同样被命名为"goodsid"，
+    // 根据这个商品id，在数据库的商品销售退货相关表中查找并删除对应的退货记录，避免冗余数据，保持业务数据的准确性，例如在处理商品退货记录清理等业务场景时使用。
+
+    // 根据商品id删除商品进货信息
+    // 用于删除与指定商品相关的进货信息，传入的参数id（同样通过@Param注解关联到SQL语句中的"goodsid"参数）作为依据，
+    // 在数据库的商品进货相关表中定位到对应的进货记录并删除，比如当商品信息变更或者不再需要某些进货历史记录时，调用该方法来清理数据。
+
+
+    // 根据商品id删除商品退货信息
+    // 按照传入的商品id，在数据库的商品退货相关表（可能是出库退货等相关业务对应的表，具体依业务和数据库设计而定）中查找并删除对应的退货记录，
+    // 保证数据库中商品退货数据与实际业务情况相符，防止出现无效或过期的退货数据，例如在退货业务流程结束后进行数据清理时使用该方法。
+
+
+    // 根据客户id删除商品销售
+    // 该方法以传入的参数id（代表客户的唯一标识符）为依据，从数据库的商品销售相关表中，查找并删除与该客户相关的所有商品销售记录，
+    // 例如在客户账号注销或者业务上不再需要该客户的销售历史数据等场景下，调用此方法来清理相应的数据，维护数据库数据的有效性和整洁性。
+
+
+    // 根据客户id删除商品销售退货信息
+    // 与deleteSaleByCustomerId类似，不过是针对商品销售退货信息进行删除操作，依据传入的客户id，在数据库的商品销售退货相关表中，
+    // 清除该客户对应的所有销售退货记录，确保数据能准确反映当前业务状态，比如在处理客户相关数据清理、业务调整等情况下使用。
+
+
+    // 加载所有库存预警商品
+    // 此方法用于从数据库中查询并返回所有符合库存预警条件的商品信息，返回的是一个包含Goods对象的列表（List<Goods>），
+    // 意味着会将数据库中那些库存数量达到预警阈值或者满足其他库存预警规则（具体规则由业务逻辑和数据库查询语句确定）的商品记录查询出来，
+    // 方便后续在业务中进行库存预警提示、补货提醒等相关操作，让业务人员及时了解库存情况并采取相应措施。

src/main/java/com/yeqifu/bus/mapper/InportMapper.java

@@ -14,3 +14,16 @@ import com.baomidou.mybatisplus.core.mapper.BaseMapper;
 public interface InportMapper extends BaseMapper<Inport> {
 
 }
+// InportMapper接口，它继承自BaseMapper<Inport>，这里的BaseMapper是MyBatis-Plus框架提供的一个基础的Mapper接口，
+// 通过继承它，InportMapper接口可以复用BaseMapper中已经定义好的一些通用的数据库操作方法，例如常见的增删改查操作方法（如insert、selectById、updateById、deleteById等），
+// 这些方法能够方便地与数据库进行交互，实现对Inport类型数据（通常代表进货相关的业务实体，其具体结构由Inport类定义）的基本持久化功能。
+
+// 同时，这个接口也可以作为一个扩展点，开发人员可以根据具体的进货业务逻辑需求，后续在这个接口中添加更多自定义的数据库操作方法，
+// 例如根据特定条件查询进货记录、关联其他表进行复杂的进货数据统计等操作方法，并且在对应的Mapper实现类（一般由MyBatis-Plus框架自动生成或者手动编写实现类）中，
+// 通过编写具体的SQL语句或者利用MyBatis-Plus提供的各种查询构建器等方式，来实现这些自定义方法与数据库的交互逻辑，进而满足更为复杂和贴合业务实际的进货数据处理需求。
+
+
+
+    // 目前该接口没有自定义额外的方法，仅继承了BaseMapper<Inport>的通用方法，意味着它暂时仅具备基础的针对Inport类型数据的数据库操作能力，
+    // 不过随着业务发展，如果有针对进货数据的特殊持久化操作需求，就可以在这里添加相应的方法定义，来完善和扩展其功能。
+

src/main/java/com/yeqifu/bus/mapper/OutportMapper.java

@@ -14,3 +14,21 @@ import com.baomidou.mybatisplus.core.mapper.BaseMapper;
 public interface OutportMapper extends BaseMapper<Outport> {
 
 }
+// OutportMapper接口，它在整个项目的数据持久化层中扮演着重要角色，主要用于处理与出货（Outport）相关的数据库操作，是连接业务逻辑层与数据库的关键纽带之一。
+
+// 该接口继承自BaseMapper<Outport>，BaseMapper是MyBatis-Plus框架提供的一个基础的通用Mapper接口，通过这种继承关系，
+// OutportMapper接口能够自动获得BaseMapper中定义好的一系列通用的数据库操作方法，比如常见的插入（insert）、根据主键查询（selectById）、
+// 根据主键更新（updateById）以及根据主键删除（deleteById）等方法，这些方法基于MyBatis-Plus的强大功能，能够便捷地与数据库进行交互，实现对Outport类型数据（通常对应着出货业务实体，
+// 其具体属性和结构由Outport类来定义）的基础持久化操作，满足了在出货业务场景下对数据进行基本的增删改查等常规需求。
+
+// 除此之外，从扩展性角度来看，这个接口还具备很强的可扩展性。随着项目中出货业务的不断发展和变化，可能会出现一些针对出货数据的特殊操作需求，
+// 例如按照特定条件（如时间范围、商品类别、供应商等）查询出货记录、关联其他相关表（如关联商品表获取商品详细信息、关联客户表查看出货对象等）进行复杂的出货数据统计分析，
+// 或者执行一些涉及多个表的复杂的数据库事务操作（比如出货同时更新库存和财务相关数据等）等情况，开发人员就可以根据这些具体的业务需求，在这个OutportMapper接口中添加自定义的方法声明，
+// 然后在对应的Mapper实现类（一般由MyBatis-Plus框架按照一定规则自动生成或者开发人员手动编写实现类）中，通过编写合适的SQL语句、运用MyBatis-Plus提供的各种查询构建器以及事务管理机制等，
+// 来实现这些自定义方法与数据库之间的交互逻辑，从而进一步完善和拓展针对出货业务数据的持久化处理功能，更好地满足项目中复杂多变的出货业务操作要求。
+
+
+
+    // 当前该接口仅继承了BaseMapper<Outport>，暂时未添加额外的自定义方法，这意味着目前它仅提供了那些基础的、通用的针对出货数据的数据库操作功能，
+    // 不过这也为后续依据实际业务发展情况来灵活扩展其功能留下了空间，方便根据出货业务的细化需求逐步完善其持久化操作能力。
+

src/main/java/com/yeqifu/bus/mapper/ProviderMapper.java

@@ -34,3 +34,27 @@ public interface ProviderMapper extends BaseMapper<Provider> {
 
 
 }
+// ProviderMapper接口，它在项目的数据持久化层负责处理与供应商（Provider）相关的数据库操作，是连接业务逻辑层和数据库的重要桥梁。
+// 该接口继承自BaseMapper<Provider>，BaseMapper是MyBatis-Plus框架提供的基础通用Mapper接口，通过继承它，ProviderMapper能够复用BaseMapper中定义好的常规数据库操作方法，
+// 例如常见的增删改查操作（像插入供应商记录、根据供应商ID查询供应商信息、更新供应商信息以及删除供应商记录等），满足对供应商数据的基本持久化需求。
+
+// 同时，针对供应商业务逻辑中的一些特定操作场景，此接口还自定义了几个额外的方法，用于处理与供应商相关联的数据的删除操作，进一步完善了在涉及供应商相关业务时的数据持久化功能。
+
+
+
+    // 根据供应商id删除商品信息
+    // 此方法用于从数据库中删除与指定供应商相关联的商品信息。通过传入的参数id（使用@Param注解将其命名为"pid"，便于在对应的SQL语句中清晰地引用该参数），
+    // 在数据库的商品表（具体表名根据实际数据库设计而定）中，依据与供应商的关联关系（通常通过外键关联，比如商品表中有指向供应商表的供应商ID字段），
+    // 找到该供应商所对应的商品记录并执行删除操作，以确保数据的一致性。例如，当某个供应商不再合作，需要清理与之相关的商品数据时，可调用该方法。
+
+
+    // 根据供应商id删除商品进货信息
+    // 其功能是依据传入的供应商id，从数据库的商品进货相关表（可能记录了每次进货的商品、供应商、进货时间等信息的表，具体依业务和数据库设计确定）中，
+    // 查找并删除与该供应商相关的所有进货记录，避免出现数据冗余或无效的进货数据关联该供应商，比如在供应商信息变更或者合作终止等情况下，用于清理对应的进货历史数据。
+
+
+    // 根据供应商id删除商品退货信息
+    // 与上述两个删除方法类似，该方法根据传入的供应商id，在数据库的商品退货相关表（比如记录商品退货的时间、数量、退货原因以及对应的供应商等信息的表）中，
+    // 定位到与该供应商相关的退货记录并进行删除操作，保证数据库中的退货数据能准确反映当前业务状态，防止出现过期或不必要的退货记录与该供应商关联，例如在整理退货数据或者更新供应商合作关系时使用。
+
+

src/main/java/com/yeqifu/bus/mapper/SalesMapper.java

@@ -14,3 +14,25 @@ import com.baomidou.mybatisplus.core.mapper.BaseMapper;
 public interface SalesMapper extends BaseMapper<Sales> {
 
 }
+// SalesMapper接口，它处于项目的数据持久化层，主要负责处理与销售（Sales）业务相关的数据持久化操作，是连接业务逻辑层与数据库的重要纽带，在整个项目架构中起着关键作用。
+
+// 该接口继承自BaseMapper<Sales>，这里的BaseMapper是MyBatis-Plus框架提供的一个基础通用Mapper接口。通过这种继承关系，
+// SalesMapper接口能够直接复用BaseMapper中已经定义好的一系列通用的数据库操作方法，像常见的插入（insert）方法，可用于向数据库中插入新的销售记录；
+// 依据主键进行查询的selectById方法，方便根据销售记录的唯一标识符（通常是主键ID）从数据库中精准获取某条销售记录的详细信息；
+// 基于主键更新记录的updateById方法，能对数据库中已存在的销售记录进行修改操作；还有通过主键删除记录的deleteById方法，用于删除数据库中对应的销售记录等。
+// 这些通用的数据库操作方法借助MyBatis-Plus的功能特性，能够高效地与数据库进行交互，实现对Sales类型的数据（通常代表销售业务实体，其具体的属性和结构由Sales类来定义）的基本持久化功能，
+// 满足了在日常销售业务场景下对销售数据进行常规的增删改查等基础操作的需求，例如添加一笔新的销售业务记录、查看特定销售业务详情、修改销售记录中的部分信息或者删除不再需要的销售记录等情况。
+
+// 从可扩展性角度来看，虽然当前SalesMapper接口暂时只是继承了BaseMapper<Sales>，并没有额外自定义其他方法，但随着项目中销售业务的不断发展和变化，
+// 后续极有可能会出现一些针对销售数据的特殊操作需求。例如，按照特定的条件（如销售时间范围、客户地区、商品分类等）来查询销售记录，
+// 或者关联其他相关数据表（比如关联客户表获取客户的详细信息、关联商品表查看商品的具体规格等）进行更为复杂的销售数据统计分析，
+// 又或者执行涉及多个表的复杂数据库事务操作（比如销售业务发生时同时更新库存表、财务相关数据表等）。一旦有这些业务需求出现，开发人员就可以根据具体的业务场景，
+// 在这个SalesMapper接口中添加相应的自定义方法声明，然后在对应的Mapper实现类（一般由MyBatis-Plus框架按照相应规则自动生成或者开发人员手动编写实现类）中，
+// 通过编写合适的SQL语句、运用MyBatis-Plus提供的各种查询构建器以及事务管理机制等，来实现这些自定义方法与数据库之间的交互逻辑，
+// 从而进一步完善和拓展针对销售业务数据的持久化处理功能，使其能够更好地适配项目中日益复杂和多样化的销售业务操作要求。
+
+
+
+    // 现阶段该接口仅继承了BaseMapper<Sales>所提供的通用数据库操作方法，尚未添加额外的自定义方法，这表明目前它主要提供的是基础的、常规的针对销售数据的数据库操作功能，
+    // 不过这也为后续依据销售业务的实际发展情况灵活扩展其功能留下了充足的空间，方便后续根据销售业务的细化需求逐步丰富其持久化操作能力，以更好地服务于整个项目的销售业务逻辑。
+

src/main/java/com/yeqifu/bus/mapper/SalesbackMapper.java

@@ -14,3 +14,24 @@ import com.baomidou.mybatisplus.core.mapper.BaseMapper;
 public interface SalesbackMapper extends BaseMapper<Salesback> {
 
 }
+// SalesbackMapper接口，它在整个项目的数据持久化层有着特定的作用，主要聚焦于处理与销售退货（Salesback）相关的数据库操作，是实现业务逻辑层与数据库之间交互的关键一环。
+
+// 该接口继承自BaseMapper<Salesback>，BaseMapper是MyBatis-Plus框架所提供的一个基础的通用Mapper接口。借助这种继承关系，
+// SalesbackMapper接口能够直接复用BaseMapper里已经定义好的一系列通用的数据库操作方法，例如常见的增删改查操作方法，像插入销售退货记录（insert方法）、
+// 根据销售退货记录的主键查询相应记录（selectById方法）、依据主键更新销售退货记录（updateById方法）以及通过主键删除销售退货记录（deleteById方法）等。
+// 这些通用方法依托MyBatis-Plus的功能机制，能够便捷地与数据库进行交互，从而实现对Salesback类型的数据（通常对应着销售退货业务实体，其具体的属性和结构由Salesback类来定义）进行基础的持久化操作，
+// 满足了在销售退货业务场景下对相关数据进行常规处理的基本需求，比如简单的添加、查询、修改以及删除单条销售退货记录等操作。
+
+// 从可扩展性方面来看，虽然当前这个接口暂时仅继承了BaseMapper<Salesback>，没有额外自定义其他方法，但随着项目中销售退货业务的不断拓展和变化，
+// 后续很可能会出现一些针对销售退货数据的特殊操作需求。例如，按照特定条件（如退货时间范围、客户类别、商品种类等）来查询销售退货记录，
+// 或者关联其他相关数据表（比如关联商品表获取退货商品的详细规格、关联客户表查看退货客户的更多信息等）进行更为复杂的销售退货数据统计分析，
+// 亦或是执行涉及多个表的复杂数据库事务操作（比如销售退货同时更新库存、财务相关数据等情况）。当出现这些业务需求时，开发人员就可以根据具体情况，
+// 在这个SalesbackMapper接口中添加自定义的方法声明，然后在对应的Mapper实现类（一般由MyBatis-Plus框架按照既定规则自动生成或者开发人员手动编写实现类）中，
+// 通过编写合适的SQL语句、运用MyBatis-Plus提供的各种查询构建器以及事务管理机制等手段，来实现这些自定义方法与数据库之间的交互逻辑，
+// 进而完善和拓展针对销售退货业务数据的持久化处理功能，使其能够更好地适应项目中复杂多变的销售退货业务操作要求。
+
+
+
+    // 目前该接口仅继承了BaseMapper<Salesback>所提供的通用方法，尚未添加额外的自定义方法，这意味着现阶段它主要提供的是基础的、通用的针对销售退货数据的数据库操作功能，
+    // 不过这也为后续依据业务发展情况灵活扩展其功能预留了空间，方便根据销售退货业务的细化需求逐步丰富其持久化操作能力。
+

src/main/java/com/yeqifu/bus/service/ICustomerService.java

@@ -17,5 +17,18 @@ public interface ICustomerService extends IService<Customer> {
      * 根据客户id删除客户
      * @param id    客户id
      */
-    void deleteCustomerById(Integer id);
+
 }
+// ICustomerService接口，它在项目的业务逻辑层扮演着重要角色，用于定义与客户（Customer）相关的业务操作方法规范，是对外提供统一的客户业务服务的接口。
+// 该接口继承自IService<Customer>，IService是MyBatis-Plus框架中定义的一个通用服务层接口，通过继承它，ICustomerService接口可以复用IService中提供的一些通用的服务方法，
+// 例如常见的增删改查操作方法（像保存客户信息、根据客户ID查询客户、更新客户信息等），这些复用的方法能够方便地与数据持久化层进行交互，实现对客户数据的基本业务处理，满足常规的客户业务操作需求。
+
+// 同时，针对客户业务逻辑中的特定需求，此接口还自定义了一个额外的方法，用于执行删除客户的操作，进一步完善了在客户管理方面的业务服务功能。
+
+
+
+    // 根据客户id删除客户
+    // 此方法用于在业务逻辑层面实现根据给定的客户id（参数id表示客户的唯一标识符），从系统中删除对应的客户信息及其相关联的数据（具体关联的数据删除情况可能要依据业务规则和数据库设计而定）。
+    // 例如，在客户注销账号、不再合作或者因数据清理等业务场景下，通过调用该方法，可以触发一系列相关操作，确保客户数据在数据库以及整个业务系统中的一致性，
+    // 可能涉及到删除客户在其他关联表（如客户订单表、客户反馈表等）中的相关记录等操作，不过具体的实现细节会在该接口的实现类中进行处理，这里主要定义了方法的规范和功能。
+

src/main/java/com/yeqifu/bus/service/IGoodsService.java

@@ -27,3 +27,26 @@ public interface IGoodsService extends IService<Goods> {
      */
     List<Goods> loadAllWarning();
 }
+// IGoodsService接口，它位于项目的业务逻辑层，起着至关重要的作用，主要用于定义各类与商品（Goods）相关的业务操作方法，是对外提供统一的商品业务服务的接口，方便其他层（如控制层等）进行调用。
+
+// 该接口继承自IService<Goods>，IService是MyBatis-Plus框架所定义的一个通用服务层接口，通过继承它，IGoodsService接口能够复用IService中已经定义好的一系列通用的服务方法，
+// 例如常见的增删改查操作方法（像保存商品信息、根据商品ID查询商品详情、更新商品信息等），这些复用的方法可以便捷地与数据持久化层（通常是对应的Mapper接口及实现类）进行交互，
+// 实现对商品数据的基础业务处理，满足常规的商品业务操作需求，保障了商品数据在整个业务系统中的流转和处理。
+
+// 除此之外，针对商品业务逻辑中的特定业务场景，此接口还自定义了两个额外的方法，进一步丰富和完善了在商品管理及相关业务方面的服务功能。
+
+
+
+    // 根据商品id删除商品
+    // 此方法用于在业务逻辑层面，依据传入的商品id（参数id代表商品的唯一标识符），从系统中删除对应的商品信息以及与之相关联的数据（具体关联数据的删除范围要依据业务规则和数据库设计来确定）。
+    // 比如，当商品下架、库存清零且不再售卖或者因数据清理等业务情况发生时，调用该方法可以触发一系列相关操作，确保商品数据在数据库以及整个业务系统中的一致性，
+    // 可能涉及到删除商品在其他关联表（如商品销售表、商品进货表、商品库存表等）中的相关记录等操作，不过具体的删除逻辑实现细节会在该接口的实现类中进行处理，这里主要是定义了该删除操作的方法规范和功能要求。
+
+
+    // 加载所有的库存预警商品
+    // 该方法用于从系统中查询并获取所有满足库存预警条件的商品信息，返回一个包含Goods对象的列表（List<Goods>）。库存预警条件通常是由业务规则预先设定好的，
+    // 例如商品库存数量低于某个设定的阈值、库存周转率达到特定标准等情况，通过调用这个方法，能够方便业务人员及时了解哪些商品的库存处于需要关注的预警状态，
+    // 以便采取相应的措施（如及时补货、调整销售策略等），其具体的查询逻辑以及判断库存预警的实现细节同样会在接口的实现类中进行编写，这里主要定义了方法的返回值类型和功能概述。
+
+
+

src/main/java/com/yeqifu/bus/service/IInportService.java

@@ -14,3 +14,23 @@ import com.baomidou.mybatisplus.extension.service.IService;
 public interface IInportService extends IService<Inport> {
 
 }
+// IInportService接口，它处于项目的业务逻辑层，主要聚焦于定义与进货（Inport）相关的业务操作方法规范，是对外提供统一的进货业务服务的接口，在整个项目架构里扮演着连接控制层与数据持久化层的关键角色。
+
+// 该接口继承自IService<Inport>，IService是MyBatis-Plus框架提供的一个基础通用服务层接口。借助这种继承关系，
+// IInportService接口能够直接复用IService中已经定义好的一系列通用的服务方法，例如常见的增删改查操作方法，像保存进货记录（insert方法）、
+// 根据进货记录的主键查询相应记录（selectById方法）、依据主键更新进货记录（updateById方法）以及通过主键删除进货记录（deleteById方法）等。
+// 这些通用的服务方法依托MyBatis-Plus的功能机制，能够方便地与数据持久化层（通常对应的是InportMapper及其实现类）进行交互，从而实现对Inport类型的数据（通常对应着进货业务实体，其具体的属性和结构由Inport类来定义）进行基础的业务处理，
+// 满足了在日常进货业务场景下对进货数据进行常规的增删改查等基础操作的需求，例如添加一笔新的进货业务记录、查看特定进货业务详情、修改进货记录中的部分信息或者删除不再需要的进货记录等情况。
+
+// 虽然当前这个接口暂时只是继承了IService<Inport>，并没有额外自定义其他方法，但随着项目中进货业务的不断拓展和变化，
+// 后续很可能会出现一些针对进货数据的特殊操作需求。例如，按照特定的条件（如进货时间范围、供应商类别、商品种类等）来查询进货记录，
+// 或者关联其他相关数据表（比如关联供应商表获取供应商的详细信息、关联商品表查看商品的具体规格等）进行更为复杂的进货数据统计分析，
+// 又或者执行涉及多个表的复杂业务操作（比如进货同时更新库存表、财务相关数据表等）。一旦有这些业务需求出现，开发人员就可以根据具体的业务场景，
+// 在这个IInportService接口中添加相应的自定义方法声明，然后在对应的服务实现类（一般由MyBatis-Plus框架按照既定规则自动生成或者开发人员手动编写实现类）中，
+// 通过编写合适的业务逻辑代码以及调用数据持久化层的方法等，来实现这些自定义方法与数据库及其他相关业务模块之间的交互逻辑，
+// 进而完善和拓展针对进货业务数据的服务处理功能，使其能够更好地适配项目中日益复杂和多样化的进货业务操作要求。
+
+
+
+    // 现阶段该接口仅继承了IService<Inport>所提供的通用服务方法，尚未添加额外的自定义方法，这表明目前它主要提供的是基础的、常规的针对进货数据的业务服务功能，
+    // 不过这也为后续依据进货业务的实际发展情况灵活扩展其功能留下了充足的空间，方便后续根据进货业务的细化需求逐步丰富其服务操作能力，以更好地服务于整个项目的进货业务逻辑。

src/main/java/com/yeqifu/bus/service/IOutportService.java

@@ -21,3 +21,21 @@ public interface IOutportService extends IService<Outport> {
      */
     void addOutport(Integer id, Integer number, String remark);
 }
+// IOutportService接口，它位于项目的业务逻辑层，起着关键的作用，主要用于定义各类与出货（Outport）相关的业务操作方法，同时也涵盖了针对进货退货这一特定业务场景的相关操作，是对外提供统一的出货及相关业务服务的接口，便于其他层（如控制层等）进行调用。
+
+// 该接口继承自IService<Outport>，IService是MyBatis-Plus框架所定义的一个通用服务层接口，通过继承它，IOutportService接口能够复用IService中已经定义好的一系列通用的服务方法，
+// 例如常见的增删改查操作方法（像保存出货记录、根据出货记录的ID查询出货详情、更新出货记录等），这些复用的方法可以便捷地与数据持久化层（通常是对应的OutportMapper及其实现类）进行交互，
+// 实现对出货数据的基础业务处理，满足常规的出货业务操作需求，保障了出货数据在整个业务系统中的流转和处理。
+
+// 除此之外，针对业务逻辑中涉及到的对商品进货进行退货处理这一特定需求，此接口还自定义了一个额外的方法，进一步丰富和完善了在出货及退货管理方面的服务功能。
+
+
+
+    // 对商品进货进行退货处理
+    // 此方法用于在业务逻辑层面，处理商品进货后的退货相关操作。它接收三个参数：
+    // - 参数id（代表进货单ID），用于明确是针对哪一笔进货业务进行退货操作，通过这个ID可以关联到对应的进货记录，确定退货操作所涉及的具体商品、供应商等相关信息，它是整个退货操作定位基础数据的关键标识。
+    // - 参数number（表示退货数量），明确了此次退货的商品具体数量，这对于后续更新库存数量、统计退货数据等操作至关重要，确保退货数量的准确性能够维护整个业务系统中数据的一致性。
+    // - 参数remark（代表备注信息），用于记录一些额外的、需要说明的关于此次退货的相关情况，比如退货原因（商品质量问题、数量不符等）、特殊的退货协商结果等内容，方便后续查看退货记录时能更全面地了解当时的业务详情。
+    // 在具体实现时，调用这个方法会触发一系列相关的业务逻辑操作，例如根据进货单ID查找对应的进货商品信息，依据退货数量更新库存（减少相应的库存数量），在数据库中记录此次退货的相关数据（生成退货记录等），
+    // 同时可能还会涉及到关联其他表进行相关数据的更新或记录（如财务相关表记录退货涉及的资金变动等），不过具体的详细实现逻辑会在该接口的实现类中进行处理，这里主要是定义了该退货操作方法的参数以及功能概述。
+

src/main/java/com/yeqifu/bus/service/IProviderService.java

@@ -19,3 +19,19 @@ public interface IProviderService extends IService<Provider> {
      */
     void deleteProviderById(Integer id);
 }
+// IProviderService接口，它处于项目的业务逻辑层，主要负责定义与供应商（Provider）相关的业务操作方法规范，是对外提供统一的供应商业务服务的接口，在整个项目架构中起着连接不同业务模块以及与数据持久化层交互的重要作用。
+
+// 该接口继承自IService<Provider>，IService是MyBatis-Plus框架提供的一个通用服务层接口，通过继承它，IProviderService接口可以复用IService中已定义好的通用服务方法，
+// 例如常见的增删改查操作方法（像保存供应商信息、根据供应商ID查询供应商详情、更新供应商信息等），这些复用的方法能够方便地与数据持久化层（通常对应的是ProviderMapper及其实现类）进行交互，
+// 实现对供应商数据的基本业务处理，满足常规的供应商业务操作需求，保障了供应商数据在整个业务系统中的正常流转与处理。
+
+// 同时，针对供应商业务中特定的删除操作需求，此接口自定义了一个额外的方法，进一步完善了在供应商管理方面的服务功能，使其能更精准地处理与供应商删除相关的业务逻辑。
+
+
+
+    // 根据供应商ID删除供应商
+    // 此方法用于在业务逻辑层面，依据传入的供应商ID（参数id表示供应商的唯一标识符），从系统中删除对应的供应商信息以及与之相关联的数据（具体关联数据的删除范围要依据业务规则和数据库设计来确定）。
+    // 例如，当供应商合作关系终止、供应商信息有误需要彻底清除或者因业务调整不再使用该供应商等场景出现时，通过调用该方法，可以触发一系列相关操作，
+    // 确保供应商数据在数据库以及整个业务系统中的一致性，可能涉及到删除该供应商在其他关联表（如商品进货表、商品销售表中与该供应商相关的记录等）中的相关记录等操作，
+    // 不过具体的删除逻辑实现细节会在该接口的实现类中进行处理，这里主要是定义了该方法的功能规范，明确了依据供应商ID来执行删除操作这一业务需求。
+

src/main/java/com/yeqifu/bus/service/ISalesService.java

@@ -14,3 +14,23 @@ import com.baomidou.mybatisplus.extension.service.IService;
 public interface ISalesService extends IService<Sales> {
 
 }
+// ISalesService接口，它处在项目的业务逻辑层，核心作用是定义与销售（Sales）相关的各类业务操作方法规范，是对外提供统一的销售业务服务的接口，在整个项目架构里充当着连接控制层与数据持久化层、协调各业务模块交互的关键角色。
+
+// 该接口继承自IService<Sales>，IService是MyBatis-Plus框架提供的一个基础通用服务层接口。借助这种继承关系，
+// ISalesService接口能够直接复用IService中已经定义好的一系列通用的服务方法，例如常见的增删改查操作方法，像保存销售记录（insert方法）、
+// 根据销售记录的主键查询相应记录（selectById方法）、依据主键更新销售记录（updateById方法）以及通过主键删除销售记录（deleteById方法）等。
+// 这些通用的服务方法依托MyBatis-Plus的功能机制，能够方便地与数据持久化层（通常对应的是SalesMapper及其实现类）进行交互，从而实现对Sales类型的数据（通常对应着销售业务实体，其具体的属性和结构由Sales类来定义）进行基础的业务处理，
+// 满足了在日常销售业务场景下对销售数据进行常规的增删改查等基础操作的需求，例如添加一笔新的销售业务记录、查看特定销售业务详情、修改销售记录中的部分信息或者删除不再需要的销售记录等情况。
+
+// 尽管当前这个接口暂时只是继承了IService<Sales>，并没有额外自定义其他方法，但随着项目中销售业务的不断拓展和变化，
+// 后续很可能会出现一些针对销售数据的特殊操作需求。例如，按照特定的条件（如销售时间范围、客户类别、商品分类等）来查询销售记录，
+// 或者关联其他相关数据表（比如关联客户表获取客户的详细信息、关联商品表查看商品的具体规格等）进行更为复杂的销售数据统计分析，
+// 又或者执行涉及多个表的复杂业务操作（比如销售业务发生时同时更新库存表、财务相关数据表等）。一旦有这些业务需求出现，开发人员就可以根据具体的业务场景，
+// 在这个ISalesService接口中添加相应的自定义方法声明，然后在对应的服务实现类（一般由MyBatis-Plus框架按照既定规则自动生成或者开发人员手动编写实现类）中，
+// 通过编写合适的业务逻辑代码以及调用数据持久化层的方法等，来实现这些自定义方法与数据库及其他相关业务模块之间的交互逻辑，
+// 进而完善和拓展针对销售业务数据的服务处理功能，使其能够更好地适配项目中日益复杂和多样化的销售业务操作要求。
+
+
+
+    // 现阶段该接口仅继承了IService<Sales>所提供的通用服务方法，尚未添加额外的自定义方法，这表明目前它主要提供的是基础的、常规的针对销售数据的业务服务功能，
+    // 不过这也为后续依据销售业务的实际发展情况灵活扩展其功能留下了充足的空间，方便后续根据销售业务的细化需求逐步丰富其服务操作能力，以更好地服务于整个项目的销售业务逻辑。

src/main/java/com/yeqifu/bus/service/ISalesbackService.java

@@ -22,3 +22,21 @@ public interface ISalesbackService extends IService<Salesback> {
     void addSalesback(Integer id, Integer number, String remark);
 
 }
+// ISalesbackService接口，它位于项目的业务逻辑层，有着十分重要的作用，主要用于定义与商品销售退货（Salesback）相关的各类业务操作方法，是对外提供统一的销售退货业务服务的接口，方便其他业务层（比如控制层）进行调用，以此来驱动整个销售退货业务流程的运转。
+
+// 该接口继承自IService<Salesback>，IService是MyBatis-Plus框架所定义的一个通用服务层接口，通过继承它，ISalesbackService接口能够复用IService中已经定义好的一系列通用服务方法，
+// 例如常见的增删改查操作方法（像保存销售退货记录、根据销售退货记录的主键查询对应记录、依据主键更新销售退货记录等），这些复用的方法可以便捷地与数据持久化层（通常对应的是SalesbackMapper及其实现类）进行交互，
+// 实现对销售退货数据的基础业务处理，满足常规的销售退货业务操作需求，保障了销售退货数据在整个业务系统中的正常流转和处理。
+
+// 此外，针对销售退货业务中核心的对商品销售进行退货处理这一特定业务场景，此接口还自定义了一个额外的方法，进一步完善和细化了在销售退货管理方面的服务功能，使其能精准地应对销售退货相关的业务操作需求。
+
+
+
+    // 对商品销售进行退货处理
+    // 此方法用于在业务逻辑层面，专门处理商品销售后的退货相关操作。它接收三个关键参数：
+    // - 参数id（代表销售单ID），这是整个退货操作的重要依据，通过它可以准确关联到对应的销售记录，进而确定此次退货所涉及的具体商品、客户、销售价格等基础信息，是定位和追溯退货业务源头的关键标识。
+    // - 参数number（表示退货数量），明确了此次退货的商品具体数量，这对于后续准确更新库存数量（将退货商品重新入库）、统计退货数据（如计算退货金额等）以及维护整个业务系统中数据的一致性都起着至关重要的作用。
+    // - 参数remark（代表备注信息），用于记录一些额外的、需要说明的关于此次退货的相关情况，例如退货原因（可能是商品质量问题、客户不满意、规格不符等）、特殊的退货协商条件（如部分退款、换货等相关约定）等内容，方便后续查看退货记录时能够更全面、详细地了解当时的业务详情。
+    // 当在业务中调用这个方法时，会触发一系列复杂的业务逻辑操作，比如依据销售单ID查找原始销售的详细信息，根据退货数量调整库存（增加相应的库存数量），在数据库中记录此次销售退货的相关数据（生成销售退货记录，包含退货时间、操作人等信息），
+    // 同时还可能涉及到关联其他业务表进行相关数据的更新或记录（如财务相关表记录退款金额、销售业绩表相应调整等），不过具体的这些详细实现逻辑会在该接口的实现类中进行处理，这里主要是定义了该销售退货操作方法的参数以及整体的功能概述。
+

src/main/java/com/yeqifu/bus/service/impl/CustomerServiceImpl.java

@@ -12,7 +12,7 @@ import org.springframework.transaction.annotation.Transactional;
 import java.io.Serializable;
 import java.util.Collection;
 
-/**
+/*
  * <p>
  * InnoDB free: 9216 kB 服务实现类
  * </p>
@@ -31,17 +31,63 @@ public class CustomerServiceImpl extends ServiceImpl<CustomerMapper, Customer> i
     public boolean save(Customer entity) {
         return super.save(entity);
     }
+    /*
+     * 方法重写自ICustomerService接口或者继承体系中父类定义的抽象方法，用于实现保存客户信息的业务逻辑。
+     * 在此方法中，它直接调用了父类的save方法（super.save(entity)）来完成实际的保存操作。
+     * 传入的参数entity是一个Customer类型的对象，代表了要保存的客户相关的数据，比如客户的姓名、联系方式、地址等各种属性信息。
+     * 父类的save方法内部大概率会与数据库（假设使用了数据库来存储客户数据，具体取决于项目的持久化方案）进行交互，
+     * 执行诸如构建SQL插入语句、处理事务等操作，将客户实体中的数据插入到对应的数据库表中。
+     * 最后根据整个保存过程是否顺利，若没有出现诸如数据库连接异常、数据约束冲突等问题，就返回true表示保存成功，
+     * 反之若出现了任何影响保存操作正常执行的情况，则返回false。
+     */
 
     @Override
     public boolean updateById(Customer entity) {
         return super.updateById(entity);
     }
+    /*
+     * 此方法是对来自ICustomerService接口或者继承体系中父类所定义抽象方法的重写，旨在实现根据客户ID更新客户信息的业务逻辑。
+     * 传入的参数entity为Customer类型的实体对象，其内部封装了包含客户ID在内的各种属性信息，其中ID用于在数据库（通常情况下，假设项目采用数据库存储客户数据）中
+     * 精准地定位到需要更新的那条客户记录。
+     * 方法内部直接调用了父类的updateById方法（super.updateById(entity)）来完成实际的更新操作，在父类的这个方法中，大概率会先基于传入实体的ID
+     * 在数据库中查找并获取对应的客户记录，随后把实体对象里更新后的各属性值，比如客户的姓名、联系方式、地址等发生变化的字段值，替换掉原记录中对应的旧值，
+     * 同时会执行诸如构建合适的SQL更新语句、处理数据库事务（确保更新操作的完整性和一致性）等相关操作，以此来完成数据的更新过程。
+     * 最后，依据整个更新操作是否顺利完成，若在执行过程中未出现如数据库连接异常、违反数据约束条件（比如唯一性约束冲突等）等问题，就返回true，表示更新成功；
+     * 若出现了任何影响更新正常执行的情况，则返回false，表示更新失败。
+     */
+
 
     @Override
     public boolean removeById(Serializable id) {
         return super.removeById(id);
     }
+    /*
+     * 此方法是对相关接口（如ICustomerService等）或者父类中定义的抽象方法的重写，其核心功能在于实现删除指定ID的客户记录这一业务操作。
+     * 这里的参数id是实现了Serializable接口的数据类型，它充当了唯一标识客户记录的关键元素，例如在常见的数据库应用场景中，
+     * 这个id往往对应着数据库表中客户记录的主键值，通过它能够精准地在存储系统（通常为数据库）里找到要删除的那条客户记录。
+     * 方法内部直接调用了父类的removeById方法（super.removeById(id)）去执行实际的删除工作。
+     * 在父类的这个removeById方法内部，会按照既定的持久化机制（可能基于某种数据库框架，比如MyBatis、Hibernate等），
+     * 先是利用传入的id在相应的数据库表中查找对应的记录，确认无误后，构造合适的删除语句（比如SQL的DELETE语句等），
+     * 并且会妥善处理相关的数据一致性事务，像是开启事务、执行删除操作、根据执行情况决定是提交事务来确认删除完成，
+     * 还是回滚事务以应对出现的异常情况（比如违反数据完整性约束等）。
+     * 最终，依据整个删除流程是否顺利完成，若没有遇到如数据库连接故障、违反外键关联限制等导致删除无法正常进行的问题，
+     * 则返回true，表示对应ID的客户记录已成功删除；反之，若出现了上述类似的阻碍删除操作的异常状况，就返回false，表示删除失败。
+     */
+
+
     @Override
+    /*
+     * 此方法重写了相关接口（比如ICustomerService接口等）或者父类中定义的抽象方法，其核心功能在于依据给定的唯一标识（id参数），
+     * 从存储系统（通常情况下是数据库）中查找并获取对应的客户信息，最终以Customer对象的形式返回获取到的客户相关数据，若未找到对应的记录则返回null。
+     *
+     * 参数id实现了Serializable接口，在实际业务场景中，尤其是当客户数据存储在数据库里时，这个id就相当于数据库表中客户记录的主键值，
+     * 是能够唯一确定一条客户记录的关键标识，凭借它可以在众多的客户记录中精准地定位到需要查找的那条记录。
+     *
+     * 方法内部直接调用了父类的getById方法（super.getById(id)）来执行实际的查找与获取操作。在父类的这个getById方法内部，
+     * 会按照既定的持久化机制（可能依托于某种数据库框架，例如MyBatis、Hibernate等），先是利用传入的id参数在对应的数据库表中进行查找，
+     * 尝试匹配到相应的客户记录。若成功找到对应的客户记录，便会依据Customer类的定义，将记录中的各个字段数据进行提取、封装，
+     * 从而构造出一个完整的Customer对象并返回；若查找后未发现符合该id标识的客户记录，就会返回null，表示此次查找获取客户信息的操作未成功。
+     */
     public Customer getById(Serializable id) {
         return super.getById(id);
     }
@@ -64,3 +110,32 @@ public class CustomerServiceImpl extends ServiceImpl<CustomerMapper, Customer> i
         this.removeById(id);
     }
 }
+
+    /*
+     * 此方法重写了（可能来自相关接口或者父类定义的抽象方法）用于删除客户相关信息的功能，其核心目的在于依据给定的客户ID，
+     * 完成一系列与该客户相关联的数据删除操作，以确保数据的完整性和关联性，整体上实现彻底删除该客户及其相关业务数据的效果。
+     *
+     * 方法接收一个Integer类型的参数id，该参数代表了要删除的客户的唯一标识符，在实际业务场景中（例如数据库存储客户及相关业务数据时），
+     * 这个id对应着数据库表中客户记录的主键值，通过它能够精准地定位到需要进行删除操作的客户相关数据记录。
+     */
+
+        // 根据客户id删除商品销售
+        /*
+         * 调用goodsMapper对象的deleteSaleByCustomerId方法，该方法（假设其所在的GoodsMapper接口或类有对应的数据库操作实现）
+         * 会依据传入的客户ID，在存储商品销售数据的数据库表（比如可能名为'sale'表等）中查找并删除与该客户相关联的所有商品销售记录。
+         * 这么做是因为客户与商品销售之间存在业务关联，当删除客户时，需要同步清理与之相关的销售数据，避免数据冗余和不一致性问题。
+         */
+
+
+        // 根据客户id删除商品销售退货
+        /*
+         * 同样地，这里调用goodsMapper的deleteSaleBackByCustomerId方法，其作用是基于传入的客户ID，
+         * 在存储商品销售退货数据的数据库表（例如名为'sale_back'表等）里查找并删除所有与该客户相关的商品销售退货记录。
+         * 这也是考虑到业务逻辑上客户与商品销售退货之间存在关联关系，删除客户时要保证相应退货数据也一并被清理掉，维持数据的关联性和准确性。
+         */
+
+
+        // 调用当前类（可能继承了某些基础服务类）的removeById方法，依据传入的客户ID，
+        // 从存储客户基本信息的数据库表（通常名为'customer'表等）中查找并删除对应的客户记录本身，完成客户基本信息的删除操作，
+        // 至此，从客户基本信息到与之关联的商品销售及销售退货等相关数据都已完成删除，实现了完整的客户相关数据删除流程。
+

src/main/java/com/yeqifu/bus/vo/InportVo.java

@@ -26,3 +26,33 @@ public class InportVo extends Inport {
     private Date endTime;
 
 }
+// InportVo类，它是一个Java类，通过继承Inport类来扩展其功能，通常用于在业务中承载更多与进货相关的数据展示、查询等操作所需的信息，
+// 比如用于接收前端传递过来的分页、时间范围筛选等参数，方便在后端进行相应的业务逻辑处理以及与数据库交互获取符合条件的进货数据。
+
+// 使用了@Data注解，该注解来自Lombok库（假设项目中引入了Lombok），它会自动为类生成常用的方法，如Getter、Setter、toString、equals和hashCode等方法，
+// 减少了手动编写这些重复代码的工作量，让代码更加简洁明了，同时也遵循了Java Bean的规范，便于对象属性的访问和操作。
+
+// @EqualsAndHashCode(callSuper = false)注解同样来自Lombok库，它用于重写equals和hashCode方法，
+// 设置callSuper = false表示在生成equals和hashCode方法时，不会调用父类（Inport类）的相应方法，而是仅基于当前类自身的属性来生成，
+// 这符合在一些特定业务场景下，只关注当前类新增或重写的属性来进行对象相等性判断和哈希码生成的需求。
+
+
+
+    // page属性用于存储当前请求的页码信息，初始值设置为1，在分页查询进货数据的业务场景中，前端通常会传递需要查看的页码数，
+    // 后端根据这个页码以及每页显示的记录数量（由limit属性决定）来从数据库中获取相应的数据，例如当page为2且limit为10时，
+    // 可以获取第2页的10条进货记录，方便实现数据的分页展示，提升用户体验，避免一次性加载过多数据。
+
+    // limit属性用于指定每页显示的记录数量，初始值设为10，它与page属性配合使用，共同确定每次分页查询时从数据库中获取的数据范围，
+    // 可以根据实际业务需求和性能考虑来调整这个值，比如在数据量较大时适当增大每页显示数量，或者为了提高页面加载速度适当减小每页显示数量。
+
+
+    // startTime属性用于接收表示时间范围起始时间的日期信息，通过添加@DateTimeFormat(pattern = "yyyy-MM-dd")注解，
+    // 可以指定前端传递过来的日期字符串的格式（这里要求为"yyyy-MM-dd"这种常见的年-月-日格式），便于后端将其正确解析为Date类型，
+    // 在查询进货数据时，这个属性可用于筛选出起始时间之后的进货记录，例如查询从某个特定日期开始的进货情况，方便进行按时间范围的数据筛选和统计分析。
+
+
+    // endTime属性与startTime属性类似，也是用于接收日期信息，同样借助@DateTimeFormat(pattern = "yyyy-MM-dd")注解来规范日期字符串的格式，
+    // 它用于指定时间范围的结束时间，在查询进货数据时，结合startTime属性，可以获取在这个时间区间内（包含起始时间和结束时间对应的当天）的进货记录，
+    // 比如查询某一个月内的进货情况，就可以分别设置相应的起始和结束日期，实现精准的时间范围筛选功能。
+
+

src/main/java/com/yeqifu/bus/vo/OutportVo.java

@@ -27,3 +27,39 @@ public class OutportVo extends Outport {
 
 
 }
+// OutportVo类，它是一个Java类，通过继承自Outport类来拓展功能，主要用于在业务场景中承载更多与出货相关的数据展示及查询等操作所需的额外信息，
+// 常作为一种数据传输对象（DTO，Data Transfer Object），在前端与后端之间传递数据，例如接收前端传来的分页、时间范围筛选等请求参数，以便后端能依据这些参数进行相应的业务处理及数据库查询操作。
+
+// 使用了@Data注解，该注解通常来自于Lombok库（前提是项目中引入了Lombok），它的作用是自动帮我们生成一系列常规的方法，像Getter（获取属性值的方法）、Setter（设置属性值的方法）、
+// toString（将对象转换为便于查看的字符串表示形式的方法）、equals（用于比较两个对象是否相等的方法）以及hashCode（生成对象哈希码的方法）等，
+// 这样能减少大量手动编写这些重复代码的工作量，让代码更加简洁直观，同时也符合Java Bean的规范要求，方便在程序中对类对象的属性进行操作和使用。
+
+// @EqualsAndHashCode(callSuper = false)注解同样是由Lombok库提供，它用于重写equals和hashCode方法，
+// 这里将callSuper设置为false，表示在生成这两个方法时，不会去调用父类（Outport类）的equals和hashCode方法逻辑，而是仅仅依据当前类（OutportVo类）自身的属性来构建相应的比较和哈希码生成逻辑，
+// 这种方式在特定业务场景下是很有必要的，比如当我们只关心当前类新增或者重写的这些属性来判断对象是否相等或者生成哈希码时，就可以这样设置。
+
+
+
+    // page属性，其类型为整数，用于记录当前请求所对应的页码信息，初始值被设定为1。在涉及出货数据分页展示和查询的业务场景中，
+    // 前端界面通常会向后端发送想要查看的页码数，而后端就依据这个page值以及每页显示的记录数量（由limit属性确定），从数据库中准确地获取相应的数据并返回给前端，
+    // 例如，当page为3且limit为10时，后端就会查询并返回第3页的10条出货记录，以此实现数据的分页管理，避免一次性加载过多数据导致页面加载缓慢等问题，提升用户体验。
+
+
+
+    // limit属性同样为整数类型，它用于指定每页应该显示的出货记录数量，初始赋值为10。这个属性和page属性协同工作，共同确定了每次分页查询时从数据库中提取的数据范围，
+    // 根据实际业务需求以及系统性能方面的考虑，可以对这个limit值进行灵活调整，比如如果出货数据量较少，为了减少用户翻页操作，可以适当增大limit值；
+    // 若担心数据量过大影响页面加载速度，则可以适当减小limit值，使其更符合业务实际情况和用户体验要求。
+
+
+
+    // startTime属性，类型为Date，用于接收前端传递过来的表示时间范围起始时间的日期信息。通过添加@DateTimeFormat(pattern = "yyyy-MM-dd")注解，
+    // 明确了前端传递的日期字符串需要遵循“yyyy-MM-dd”这种常见的年-月-日格式，后端在接收到这样格式的字符串后，会将其正确解析并转换为Date类型进行存储和后续使用，
+    // 在查询出货数据时，该属性发挥着重要作用，它可以用来筛选出起始时间之后的出货记录，例如想要查询从某一特定日期开始的出货情况时，就可以通过设置这个startTime属性来实现时间范围的筛选，
+    // 方便进行基于时间维度的数据统计分析以及业务查询操作。
+
+
+
+    // endTime属性与startTime属性类似，也是用来接收日期信息的，类型同样为Date，同样应用了@DateTimeFormat(pattern = "yyyy-MM-dd")注解来规范日期字符串的格式，
+    // 它的作用是指定时间范围的结束时间，在进行出货数据查询时，与startTime属性配合使用，就能获取到处于这个时间区间内（包含起始时间和结束时间对应的当天）的所有出货记录，
+    // 例如，若要查询某个月内的出货情况，只需分别设置好对应的起始和结束日期，就能精准地筛选出符合要求的出货数据，为业务分析、报表生成等操作提供准确的数据基础。
+

src/main/java/com/yeqifu/bus/vo/ProviderVo.java

@@ -25,3 +25,31 @@ public class ProviderVo extends Provider{
     private Integer[] ids;
 
 }
+// ProviderVo类，它是一个Java类，通过继承Provider类来扩展其功能，在供应商相关的业务场景中，通常用于承载更多特定业务操作所需要的额外信息，
+// 常作为数据传输对象（DTO，Data Transfer Object），在不同的业务层（比如前端与后端之间）传递数据，便于根据业务需求进行相应的处理和操作。
+
+// 使用了@Data注解，该注解一般来自Lombok库（假设项目中引入了Lombok），它会自动为类生成一些常用的方法，像获取属性值的Getter方法、设置属性值的Setter方法、
+// 用于将对象转换为方便查看的字符串表示形式的toString方法、用于比较两个对象是否相等的equals方法以及生成对象哈希码的hashCode方法等，
+// 这样能减少手动编写这些重复代码的工作量，使代码更加简洁明了，同时也遵循了Java Bean的规范，方便对类对象的属性进行操作和访问。
+
+// @EqualsAndHashCode(callSuper = false)注解同样来自Lombok库，用于重写equals和hashCode方法，
+// 这里设置callSuper为false，表示在生成这两个方法时，不会调用父类（Provider类）的equals和hashCode方法逻辑，而是仅仅依据当前类（ProviderVo类）自身的属性来构建相应的判断对象相等和生成哈希码的逻辑，
+// 符合在一些业务场景下，只关注当前类新增或修改的属性来进行对象比较等操作的需求。
+
+
+
+    /**
+     * 分页参数，当前是第一页，每页10条数据
+     * 在涉及供应商数据展示、查询等业务场景中，为了便于分页展示大量的供应商信息，提高用户查看数据的体验，
+     * page属性用于表示当前请求的页码数，初始值设为1，意味着默认展示第一页的数据。
+     * limit属性则用于指定每页显示的供应商记录数量，设置为10，即每页会展示10条供应商相关信息，
+     * 后端可以根据这两个参数（page和limit）从数据库中获取相应范围的供应商数据进行返回，例如当page为2且limit为10时，就获取并返回第2页的10条供应商记录。
+     */
+
+
+    /**
+     * 批量删除供应商，存放供应商ID的数组
+     * 在进行批量删除供应商的业务操作时，需要指定要删除的供应商的唯一标识符，这个ids属性就是用于存储多个供应商的ID信息，
+     * 它是一个整数类型的数组，前端可以将需要批量删除的供应商的ID收集起来放入这个数组中，然后传递给后端，后端接收到后，
+     * 就可以依据数组中的ID值，从数据库中找到对应的供应商记录并执行删除操作，实现一次性删除多个供应商数据的功能，提高删除操作的效率。
+     */

src/main/java/com/yeqifu/bus/vo/SalesVo.java

@@ -26,3 +26,39 @@ public class SalesVo extends Sales {
     private Date endTime;
 
 }
+// SalesVo类，它是一个Java类，通过继承Sales类来进行功能扩展，在销售业务相关的应用场景中，常作为一种数据传输对象（DTO，Data Transfer Object）使用，
+// 用于在不同的业务层级（比如前端与后端之间）传递与销售业务相关的数据，同时承载了一些额外的、便于进行数据查询和展示等操作所需的信息。
+
+// 使用了@Data注解，该注解通常由Lombok库（前提是项目中引入了Lombok）提供支持，其作用是自动为类生成多个常用的方法，包含用于获取属性值的Getter方法、
+// 设置属性值的Setter方法、将对象转换为易读字符串表示形式的toString方法、用于判断两个对象是否相等的equals方法以及生成对象哈希码的hashCode方法等。
+// 借助@Data注解能够有效减少手动编写这些重复代码的工作量，让代码结构更加简洁紧凑，并且遵循Java Bean的规范，方便后续在业务逻辑中对类对象的属性进行操作和处理。
+
+// @EqualsAndHashCode(callSuper = false)注解同样来自Lombok库，它主要用于重写equals和hashCode方法。在这里将callSuper设置为false，表示在生成这两个方法时，
+// 不会去调用父类（Sales类）的equals和hashCode方法逻辑，而是仅仅依据当前类（SalesVo类）自身的属性来构建相应的对象相等性判断以及哈希码生成的逻辑，
+// 这符合在一些特定业务场景下，更关注当前类自身新增或修改的属性对对象比较和哈希码影响的需求。
+
+
+
+    // page属性，其类型为整数，用于存储当前请求对应的页码信息，在销售数据分页展示和查询的业务场景中有着重要作用。
+    // 它的初始值设定为1，表示默认情况下，当没有明确指定页码时，代表请求查看的是第一页的数据。例如，在前端展示销售记录列表时，
+    // 如果用户未进行页码切换操作或者首次访问页面，后端就会依据这个默认的page值以及每页显示的记录数量（由limit属性决定），从数据库中获取相应的数据返回给前端，
+    // 通过这种分页机制，能够避免一次性加载大量销售记录导致页面加载缓慢的问题，提升用户查看数据的体验，方便用户按页浏览销售信息。
+
+
+
+    // limit属性也是整数类型，用于指定每页显示的销售记录数量，初始赋值为10。它与page属性协同工作，共同确定每次分页查询时从数据库中获取的数据范围，
+    // 根据实际业务需求以及系统性能状况等因素，可以对limit的值进行灵活调整，比如在销售数据量较少时，为减少用户翻页操作，可适当增大limit值；
+    // 若数据量较大，为保证页面加载速度，可适当减小limit值，使分页展示更贴合实际业务情况，满足不同场景下的数据查看需求。
+
+
+
+    // startTime属性，类型为Date，主要用于接收前端传递过来的、表示时间范围起始时间的日期信息。通过添加@DateTimeFormat(pattern = "yyyy-MM-dd")注解，
+    // 明确了前端传递的日期字符串需要遵循“yyyy-MM-dd”这种常见的年-月-日格式，后端接收到符合此格式的字符串后，会将其准确地解析并转换为Date类型进行存储和后续使用，
+    // 在查询销售数据时，startTime属性可用于筛选出起始时间之后的销售记录，例如，若想查询从某个特定日期开始的销售情况，通过设置相应的startTime值就能实现按时间范围筛选数据，
+    // 便于进行基于时间维度的销售数据统计分析、业务查询以及生成相关报表等操作，为企业了解销售趋势、评估业务绩效等提供有力的数据依据。
+
+
+    // endTime属性与startTime属性类似，同样是用于接收日期信息的属性，类型为Date，并且也添加了@DateTimeFormat(pattern = "yyyy-MM-dd")注解来规范日期字符串格式，
+    // 它的作用是指定时间范围的结束时间，在查询销售数据时，与startTime属性配合使用，能够获取到处于该时间区间内（包含起始时间和结束时间对应的当天）的所有销售记录，
+    // 比如，若要查询某个月内的销售情况，只需分别设置好对应的起始和结束日期，后端就能精准地筛选出该时间段内的销售数据，方便对特定时间段内的销售业务进行深入分析和总结。
+

src/main/java/com/yeqifu/bus/vo/SalesbackVo.java

@@ -27,3 +27,42 @@ public class SalesbackVo extends Salesback {
 
 
 }
+// SalesbackVo类，它是一个Java类，通过继承Salesback类实现功能的拓展，主要用于在销售退货相关的业务场景中，承载更多满足特定业务操作和数据展示需求的额外信息，
+// 通常扮演数据传输对象（DTO，Data Transfer Object）的角色，负责在系统的不同层级（比如前端与后端之间）传递数据，便于后端依据接收到的信息进行相应的业务逻辑处理以及与数据库的交互操作。
+
+// 使用了@Data注解，这个注解一般是借助Lombok库（前提是项目中引入了Lombok工具）来发挥作用的。它能够自动为类生成一系列常规的方法，涵盖了Getter（用于获取类中各个属性值的方法）、
+// Setter（用来设置属性值的方法）、toString（将对象转换为便于查看和理解的字符串表示形式的方法）、equals（用于比较两个对象是否相等的方法）以及hashCode（生成对象哈希码的方法）等。
+// 通过使用@Data注解，能极大地减少手动编写这些重复代码的工作量，让代码结构更加简洁清晰，同时也遵循了Java Bean的规范要求，方便在整个项目中对类对象的属性进行便捷的操作与访问。
+
+// @EqualsAndHashCode(callSuper = false)注解同样来源于Lombok库，它主要用于重写equals和hashCode这两个方法。
+// 此处将callSuper设置为false，表示在生成equals和hashCode方法的逻辑时，不会去调用父类（Salesback类）对应的方法逻辑，而是仅仅依据当前类（SalesbackVo类）自身所定义的属性来构建判断对象相等以及生成哈希码的逻辑，
+// 这在一些特定的业务场景下是很有必要的，例如当我们重点关注的是当前类新添加或者重定义的这些属性对对象相等性及哈希码的影响时，这样的设置就能满足相应需求。
+
+
+
+    // page属性，其类型为整数，主要用于表示当前请求所对应的页码信息，在销售退货数据分页展示以及查询的业务场景中起着关键作用。
+    // 它的初始值被设定为1，意味着在默认情况下，当没有特别指定页码时，系统会将其视作请求查看第一页的数据。例如，在前端页面展示销售退货记录时，
+    // 如果用户没有手动切换页码或者首次访问相关页面，后端就会根据这个默认的page值（也就是1）以及每页显示的记录数量（由limit属性确定），从数据库中获取相应的数据返回给前端进行展示，
+    // 以此实现数据的分页管理，避免一次性加载过多的销售退货记录导致页面加载缓慢、用户体验不佳等问题，使得用户能够更方便、高效地查看数据。
+
+
+
+    // limit属性同样是整数类型，它用于明确指定每页应当显示的销售退货记录的数量，初始赋值为10。在分页查询销售退货数据的过程中，
+    // limit属性和page属性相互配合，共同确定了每次从数据库中提取数据的范围。可以根据实际业务的具体情况以及系统性能方面的考量，对这个limit值进行灵活的调整，
+    // 比如，如果销售退货记录的数据量相对较少，为了减少用户翻页操作的频率，提升查看效率，可以适当增大limit的值；相反，如果数据量较大，担心页面加载速度受到影响，
+    // 则可以适当减小limit的值，确保系统在不同的数据量情况下都能提供较好的用户体验，满足业务操作和数据展示的实际需求。
+
+
+
+    // startTime属性，类型为Date，其核心作用是接收前端传递过来的、表示时间范围起始时间的日期信息。通过添加@DateTimeFormat(pattern = "yyyy-MM-dd")注解，
+    // 明确规定了前端传递的日期字符串必须遵循“yyyy-MM-dd”这种常见的、标准化的年-月-日格式，后端在接收到符合该格式的字符串后，能够准确地将其解析并转换为Date类型进行存储与后续的业务处理，
+    // 在针对销售退货数据进行查询操作时，startTime属性能够帮助筛选出起始时间之后所发生的销售退货记录，例如，当需要查询从某个特定日期开始的销售退货情况时，
+    // 就可以通过设置相应的startTime值来精准地筛选出符合时间范围要求的记录，从而方便进行基于时间维度的数据统计分析、业务查询以及报表生成等操作，为相关业务决策提供有力的数据支持。
+
+
+
+    // endTime属性与startTime属性类似，同样是用于接收日期信息的属性，其类型也为Date，并且同样应用了@DateTimeFormat(pattern = "yyyy-MM-dd")注解来规范前端传递日期字符串的格式，
+    // 它的主要用途是指定时间范围的结束时间。在查询销售退货数据时，endTime属性与startTime属性协同配合，二者共同确定了一个完整的时间区间，后端可以依据这个时间区间，
+    // 获取到处于该区间内（包含起始时间和结束时间所对应的当天）的所有销售退货记录，例如，若要查询某个月内的销售退货情况，只需在前端按照要求分别设置好对应的起始和结束日期，
+    // 后端就能准确地筛选出该月内的所有销售退货数据，为进一步深入分析销售退货趋势、原因等业务操作提供准确、详细的数据基础，助力企业更好地管理销售退货业务。
+

src/main/java/com/yeqifu/sys/common/CacheBean.java

@@ -7,19 +7,29 @@ import com.alibaba.fastjson.JSON;
  * @Date: 2019/12/20 18:40
  */
 public class CacheBean {
-
+    // 成员变量key，用于存储缓存数据的唯一标识符，也就是“键”。在缓存体系里，通过这个键可以精准地定位和获取对应的缓存数据，
+    // 其取值通常依据具体的业务规则和数据特点来确定，比如在缓存用户登录信息时，可能用用户名作为键；缓存商品详情时，以商品编号作为键等，
+    // 它的类型为String，确保了键的简洁性和通用性，便于在不同的缓存存储实现（如内存缓存、基于Redis等的分布式缓存）中进行操作
     private String key;
-
+    // 成员变量value，用来存放实际的缓存数据内容，类型为Object，这使得它具有很强的通用性，能够容纳各种各样的Java对象，
+    // 可以是简单的基础数据类型包装类对象（如Integer、String等），也可以是复杂的自定义业务实体对象（如表示用户信息的User类对象、订单信息的Order类对象），
+    // 甚至是包含多个元素的集合类型（如List、Map等），从而满足不同业务场景下多样化的缓存数据存储需求。
     private Object value;
-
+    // 默认构造函数，它的主要作用是提供一种创建CacheBean对象的默认方式，当使用这个构造函数创建对象时，
+    // 生成的CacheBean实例的key和value属性初始值都为null，后续可以通过相应的set方法来为其赋予具体的值，
+    // 这种方式适用于那些需要先创建对象，再根据具体业务逻辑逐步初始化键值的情况，增加了创建对象的灵活性。
     public CacheBean() {
     }
-
+    // 带参数的构造函数，通过传入指定的字符串类型的key和任意类型的Object对象value，在创建CacheBean对象的同时，
+    // 直接将传入的参数赋值给对象的对应属性，完成对键值对的初始化，使得创建一个带有特定键值的CacheBean对象更加便捷高效，
+    // 常用于已知要缓存的数据及其对应标识的场景，例如明确要缓存某个商品信息，就可以直接传入商品ID作为键和商品对象作为值来快速构建CacheBean对象用于缓存。
     public CacheBean(String key, Object value) {
         this.key = key;
         this.value = value;
     }
 
+    // 外部代码在需要知晓缓存数据的键时（比如在从缓存中查找、删除特定缓存项等操作时），可以调用这个方法获取对应的键信息，
+    // 该方法遵循Java中常规的属性访问规范，保证了对私有属性key的安全访问。
     public String getKey() {
         return key;
     }
@@ -27,6 +37,10 @@ public class CacheBean {
     public void setKey(String key) {
         this.key = key;
     }
+    // 获取值（value）的访问器方法，这个方法在返回缓存数据的值时，会先对存储的Object类型的value进行JSON序列化操作（假设项目中引入了相应的JSON处理库，如FastJSON、Jackson等），
+    // 将其转换为JSON字符串格式后再返回。之所以这样做，是因为JSON字符串具有良好的跨平台性、可读性以及便于存储和传输的特点，
+    // 在缓存系统中，无论是内存缓存还是分布式缓存，将数据转换为JSON字符串形式能够更好地适配不同的存储介质，并且后续在获取缓存数据后，
+    // 也可以方便地通过JSON反序列化操作还原成原始的Java对象，以便在业务逻辑中进行相应的处理，符合缓存数据存储和使用的一般性要求。
 
     public Object getValue() {
         return JSON.toJSON(value).toString();
@@ -36,3 +50,5 @@ public class CacheBean {
         this.value = value;
     }
 }
+// 设置值（value）的修改器方法，用于让外部代码根据业务逻辑变化（例如缓存的数据发生更新、重新缓存新的数据等情况）来改变当前CacheBean对象中存储的具体缓存数据内容，
+// 通过调用这个方法，可以确保缓存中的数据始终与实际业务数据保持同步（在缓存有效期内），保证业务操作获取到的缓存数据是最新且准确的

src/main/java/com/yeqifu/sys/common/PinyinUtils.java

@@ -19,12 +19,17 @@ public class PinyinUtils {
      *  返回一个拼音字符串，并且首字母大写
      */
     public static String getPingYin(String inputString) {
+        // 创建一个HanyuPinyinOutputFormat对象，用于设置拼音输出的格式，它决定了转换后的拼音在大小写、声调、特殊字符处理等方面的呈现形式。
         HanyuPinyinOutputFormat format = new HanyuPinyinOutputFormat();
+        // 设置拼音输出的大小写格式为小写，即将转换后的拼音字母全部转换为小写形式，符合常见的拼音使用习惯。
         format.setCaseType(HanyuPinyinCaseType.LOWERCASE);
+        // 设置拼音输出的大小写格式为小写，即将转换后的拼音字母全部转换为小写形式，符合常见的拼音使用习惯。
         format.setToneType(HanyuPinyinToneType.WITHOUT_TONE);
+        // 设置拼音输出对于ü这个特殊元音字符的处理方式，设置为WITH_V，表示将ü输出为“v”，例如“绿”的拼音会输出为“lv”。
         format.setVCharType(HanyuPinyinVCharType.WITH_V);
         String output = "";
         if (inputString != null && inputString.length() > 0 && !"null".equals(inputString)) {
+            // 将输入的字符串去除首尾空白字符后转换为字符数组，方便逐个字符进行判断和处理，看其是汉字还是非汉字字符。
             char[] input = inputString.trim().toCharArray();
             try {
                 for (int i = 0; i < input.length; i++) {
@@ -42,6 +47,8 @@ public class PinyinUtils {
             return "*";
         }
         return output;
+        // main方法，是Java程序的入口点，用于测试getPingYin方法的功能。
+// 在这里调用了getPingYin方法，传入字符串"落亦"作为参数进行测试，并将返回的拼音结果输出到控制台，方便查看转换效果。
     }
 
     public static void main(String[] args) {

src/main/java/com/yeqifu/sys/common/ResultObj.java

@@ -12,13 +12,22 @@ import lombok.NoArgsConstructor;
 @AllArgsConstructor
 @NoArgsConstructor
 public class ResultObj {
+// 假设这段代码位于一个名为（例如）ResultObj的类中，此类用于统一封装操作结果相关的信息，方便在整个项目中以标准化的方式返回操作结果给调用者。
 
+    // 成员变量code，用于存储表示操作结果的状态码，通常会依据一定的规则来设定不同的值以代表不同的结果状态，
+// 例如可以参考常见的HTTP状态码的思路，或者项目自定义的一套状态码规范，通过这个状态码，调用者能快速判断操作是成功还是失败等情况。
     private Integer code;
     private String msg;
+    // 以下是一系列静态常量对象的定义，它们都是ResultObj类型，用于表示不同业务操作的特定结果状态，方便在代码中直接引用这些预定义好的结果对象，
+// 保持整个项目中操作结果返回的一致性和规范性，并且使得代码的可读性更高，一看便知具体代表的是什么操作结果。
+    // 表示登录操作成功的静态常量对象，其状态码使用了Constast类中定义的表示成功的状态码（Constast.OK，值为200），
+// 对应的提示信息为"登陆成功"，在登录相关业务逻辑执行成功后，可以返回这个对象来告知调用者登录操作顺利完成。
 
     public static final ResultObj LOGIN_SUCCESS=new ResultObj(Constast.OK,"登陆成功");
     public static final ResultObj LOGIN_ERROR_PASS=new ResultObj(Constast.ERROR,"用户名或密码错误");
     public static final ResultObj LOGIN_ERROR_CODE=new ResultObj(Constast.ERROR,"验证码错误");
+    // 表示登录操作中因用户名或密码错误导致失败的静态常量对象，状态码采用Constast类中定义的表示错误的状态码（Constast.ERROR，值为 -1），
+// 提示信息为"用户名或密码错误"，当登录验证时发现用户名或密码不匹配的情况，就可以返回这个对象向调用者说明登录失败的原因。
 
     public static final ResultObj ADD_SUCCESS = new ResultObj(Constast.OK,"添加成功");
     public static final ResultObj ADD_ERROR = new ResultObj(Constast.ERROR,"添加失败");

src/main/java/com/yeqifu/sys/common/TreeNodeBuilder.java

@@ -6,20 +6,31 @@ import java.util.List;
  * 把没有层级关系的集合变成有层级关系的集合
  * @Author: 落亦-
  * @Date: 2019/11/22 16:31
- */
+ */// TreeNodeBuilder类，其主要作用是用于构建树形结构数据，通常适用于处理具有父子层级关系的数据，例如菜单结构、组织架构等场景下，
+// 将扁平化的节点列表转换为具有层级关系的树形结构，方便后续在前端展示或者其他需要按照树形结构处理数据的业务逻辑中使用。
 public class TreeNodeBuilder {
+    // build静态方法，是这个类的核心方法，用于根据给定的扁平化的TreeNode节点列表以及顶层节点的父ID（topPid），构建出树形结构的节点列表。
+    // 参数treeNodes是一个包含TreeNode类型元素的列表，代表了所有需要构建树形结构的原始节点数据，这些节点包含了自身的ID、父ID以及子节点列表等信息（假设TreeNode类有相应的属性和方法来支持这些操作）。
+    // 参数topPid是一个整数类型，表示顶层节点的父ID，通过这个值可以筛选出树形结构的根节点，进而构建整个树形结构。
     public static List<TreeNode> build(List<TreeNode> treeNodes, Integer topPid) {
+        // 创建一个新的ArrayList<TreeNode>对象nodes，用于存储最终构建好的树形结构的节点列表，初始时它为空，后续会不断添加符合树形结构的节点到这个列表中
         List<TreeNode> nodes = new ArrayList<TreeNode>();
-        for (TreeNode n1 : treeNodes) {
+        for (TreeNode n1 : treeNodes)
+        {
             if (n1.getPid()==topPid){
                 nodes.add(n1);
             }
+            // 内层循环，再次遍历原始节点列表treeNodes中的每一个节点n2，这个循环的目的是为已经找到的第一层节点（或后续层级的父节点）寻找其直接子节点，
+            // 并将子节点添加到对应父节点的子节点列表中（通过n1.getChildren().add(n2)操作，假设TreeNode类有一个名为getChildren的方法返回子节点列表，并且该列表支持添加元素操作），
+            // 以此来构建完整的树形结构，将扁平化的节点之间的父子关系在树形结构中体现出来。
             for (TreeNode n2 : treeNodes) {
                 if (n1.getId()==n2.getPid()){
                     n1.getChildren().add(n2);
                 }
             }
         }
+        // 返回构建好的树形结构的节点列表nodes，这个列表中的节点已经按照父子关系组织好了，形成了一个完整的树形结构，
+        // 可以用于后续诸如在前端以树形菜单的形式展示、按照树形结构进行数据查询或权限控制等相关业务操作。
         return nodes;
     }
 }

src/main/java/com/yeqifu/sys/service/impl/DeptServiceImpl.java

@@ -18,30 +18,49 @@ import java.io.Serializable;
  * @author luoyi-
  * @since 2019-11-26
  */
+// DeptServiceImpl类，它是一个服务层（Service Layer）的实现类，主要负责处理与部门（Dept）相关的业务逻辑操作，
+// 并与数据持久化层进行交互，实现对部门数据的增删改查等功能。
+// 使用@Service注解将这个类标记为Spring框架中的一个服务组件，意味着Spring容器会对其进行管理，自动创建实例并处理依赖注入等相关操作，方便在其他组件中进行调用。
+// 同时添加了@Transactional注解，用于开启事务管理功能，保证在这个类中执行的多个数据库操作（如涉及到多个增删改操作的业务方法）要么全部成功提交，要么全部失败回滚，
+// 以此确保数据的一致性和完整性，常用于处理复杂的业务逻辑场景中涉及到多个数据持久化操作的情况。
 @Service
 @Transactional
 public class DeptServiceImpl extends ServiceImpl<DeptMapper, Dept> implements IDeptService {
-
+    // 重写了IDeptService接口（假设存在该接口，用于定义部门相关业务逻辑方法的规范）中的getById方法，
+    // 此方法的功能是根据给定的唯一标识符（id，实现了Serializable接口，通常对应数据库表中部门记录的主键值），
+    // 从数据库中获取对应的部门信息，并以Dept对象的形式返回。
+    // 在这个实现中，直接调用了父类（ServiceImpl<DeptMapper, Dept>）的getById方法，利用了MyBatis-Plus框架提供的通用数据持久化操作功能来执行实际的查询操作，
+    // 从对应的数据库表中查找并返回符合条件的部门记录，如果未找到则返回null。
     @Override
     public Dept getById(Serializable id) {
         return super.getById(id);
     }
+    // 重写了IDeptService接口中的update方法，该方法用于根据给定的部门实体对象（entity）以及更新条件封装对象（updateWrapper，用于构建复杂的更新条件），
+    // 对数据库中的部门记录进行更新操作，比如修改部门的名称、负责人等信息。
+    // 在这里同样是调用了父类的update方法，借助MyBatis-Plus框架提供的机制，依据传入的参数构建合适的SQL更新语句，
+    // 然后与数据库进行交互，执行更新操作，并返回一个布尔值表示更新操作是否成功，true表示成功，false表示失败（例如未找到符合条件的记录等情况）。
 
     @Override
     public boolean update(Dept entity, Wrapper<Dept> updateWrapper){
         return super.update(entity,updateWrapper);
     }
-
+    // 重写IDeptService接口中的updateById方法，其功能是根据传入的部门实体对象（entity）的主键值（通常是部门ID），
+    // 对数据库中对应的部门记录进行更新操作，该方法相对update方法来说，更新条件更简单直接，就是依据实体对象自身携带的主键来定位记录进行更新。
+    // 实现中也是依赖父类的同名方法，利用MyBatis-Plus的功能，生成相应的SQL更新语句并与数据库交互，最后返回更新操作是否成功的布尔值结果。
     @Override
     public boolean updateById(Dept entity){
         return super.updateById(entity);
     }
-
+    // 重写IDeptService接口中的removeById方法，用于根据给定的唯一标识符（id），从数据库中删除对应的部门记录，
+    // 调用父类的removeById方法，通过MyBatis-Plus框架来构建并执行SQL删除语句，实现从数据库表中移除相应部门数据的操作，
+    // 同样返回一个布尔值来表示删除操作是否成功，成功返回true，失败（如未找到对应记录等原因）返回false。
     @Override
     public boolean removeById(Serializable id){
         return super.removeById(id);
     }
-
+    // 重写IDeptService接口中的save方法，其核心功能是将传入的部门实体对象（entity）保存到数据库中，
+    // 如果实体对象的主键值（如部门ID）为空或者不存在，会执行插入操作（例如新增一个部门记录）；若主键值已存在，则执行更新操作（覆盖原有记录），
+    // 这里通过调用父类的save方法，借助MyBatis-Plus框架的功能来自动判断并执行相应的数据库持久化操作，最后返回表示操作是否成功的布尔值结果。
     @Override
     public boolean save(Dept entity) {
         return super.save(entity);

src/main/java/com/yeqifu/sys/service/impl/LoginfoServiceImpl.java

@@ -20,3 +20,19 @@ import org.springframework.transaction.annotation.Transactional;
 public class LoginfoServiceImpl extends ServiceImpl<LoginfoMapper, Loginfo> implements ILoginfoService {
 
 }
+// 在整个项目架构里起着承上启下的作用，一方面承接来自控制层（如Controller）的业务请求，另一方面与数据持久化层（通过LoginfoMapper）交互，实现对日志信息的各种操作。
+
+// 使用@Service注解将该类标记为Spring框架下的一个服务组件，这意味着Spring容器会对其进行管理，自动创建类的实例，并处理依赖注入等相关操作，
+// 方便在项目的其他组件（比如其他服务类、控制器类等）中进行调用，确保各个组件之间可以低耦合地协同工作。
+
+// 同时添加了@Transactional注解，用于开启事务管理功能。在处理日志信息相关业务时，可能会涉及到多个数据库操作（例如同时插入多条关联的日志记录、更新日志状态等情况），
+// 这个注解能保证这些相关的数据库操作作为一个整体，要么全部成功提交到数据库，要么在出现任何异常情况时全部失败回滚，从而确保了数据库中日志数据的一致性和完整性，
+// 是保障数据可靠处理的重要机制，尤其适用于复杂的日志业务逻辑场景。
+
+// 此类继承自ServiceImpl<LoginfoMapper, Loginfo>，意味着它复用了MyBatis-Plus框架提供的通用服务层实现的功能，比如常见的增删改查等基础数据库操作方法都可以直接调用或者按需重写，
+// 同时又实现了ILoginfoService接口（假设存在该接口，用于规范定义日志信息相关的业务逻辑方法），这表明它遵循该接口所约定的方法签名，
+// 为外部调用提供了统一的、符合业务需求的日志信息处理方法，方便进行诸如根据条件查询日志、保存新的日志记录、更新日志详情等操作。
+
+// 虽然当前类中暂时没有重写任何来自ILoginfoService接口或者父类ServiceImpl的方法，但按照常规的业务扩展逻辑，
+// 后续可以根据具体的日志信息业务需求，在这里重写相应的方法，例如添加一些特定的业务验证逻辑在保存日志记录前（重写save方法），
+// 或者自定义复杂的查询条件来获取特定的日志信息（重写查询相关方法等），以此来完善针对日志信息的个性化业务处理功能。

src/main/java/com/yeqifu/sys/service/impl/NoticeServiceImpl.java

@@ -15,8 +15,30 @@ import org.springframework.transaction.annotation.Transactional;
  * @author luoyi-
  * @since 2019-11-25
  */
+// NoticeServiceImpl类，它在项目的服务层（Service Layer）中承担着处理通知（Notice）相关业务逻辑的重要职责，
+// 作为连接控制层（例如接收前端请求的Controller层）与数据持久化层（通过NoticeMapper与数据库交互）的关键纽带，实现对通知信息的各种操作与管理，
+// 像是创建新通知、更新通知内容、删除通知以及查询通知详情等业务功能，都可以在这个类中通过相应的方法来完成。
+
+// @Service注解将该类标识为Spring框架下的一个服务组件，这一标记使得Spring容器能够识别并管理这个类，
+// Spring会自动为其创建实例，并且处理依赖注入等操作，从而方便其他组件（比如控制器类、其他服务类等）在需要时对它进行调用，
+// 保证了整个项目中各个组件之间可以以一种低耦合、易于维护和扩展的方式协同工作。
+
+// @Transactional注解在此处开启了事务管理功能，考虑到通知相关业务逻辑可能涉及到多个数据库操作步骤，例如在发布一个新通知时，
+// 可能需要同时向数据库中插入通知主体内容、关联相关的接收对象信息以及记录发布记录等多个操作，使用该注解能够确保这些操作作为一个整体，
+// 要么全部成功提交到数据库中，维持数据的一致性和完整性；要么在出现任何异常情况时全部回滚，避免出现部分操作成功、部分操作失败而导致的数据不一致问题，
+// 这对于保障通知业务逻辑的可靠性和数据准确性起着至关重要的作用，特别是在复杂的业务场景下尤为关键。
+
+// 此类继承自ServiceImpl<NoticeMapper, Notice>，这意味着它可以利用MyBatis-Plus框架提供的通用服务层实现功能，
+// 例如已经内置的一些基础的增删改查方法，能直接调用这些方法来与数据库进行交互，完成常规的通知数据操作，减少了重复编写数据库操作代码的工作量。
+// 同时，它还实现了INoticeService接口（假设存在这个接口，用于规范定义通知相关的业务逻辑方法集合），
+// 通过实现该接口，NoticeServiceImpl类对外提供了统一的、符合业务需求的通知业务处理方法，方便其他层（如控制层）按照接口约定的方法签名来调用相应的服务，
+// 确保整个项目在处理通知业务时接口的一致性和规范性，便于后续的代码维护与功能扩展
 @Service
 @Transactional
 public class NoticeServiceImpl extends ServiceImpl<NoticeMapper, Notice> implements INoticeService {
 
 }
+// 尽管当前代码中没有显式地重写INoticeService接口或者父类ServiceImpl中的方法，但从业务扩展的角度来看，
+// 后续可以根据具体的通知业务场景需求，在这里重写相关方法来添加特定的业务逻辑，比如在保存通知时进行一些数据合法性验证（重写save方法），
+// 或者定制复杂的查询条件来获取满足特定要求的通知列表（重写查询相关方法）等，以此来完善和细化针对通知信息的个性化业务处理功能，
+// 更好地满足项目中不断变化的通知业务操作需求。

src/main/java/com/yeqifu/sys/service/impl/PermissionServiceImpl.java

@@ -20,7 +20,10 @@ import java.io.Serializable;
 @Service
 @Transactional
 public class PermissionServiceImpl extends ServiceImpl<PermissionMapper, Permission> implements IPermissionService {
-
+    // getBaseMapper()方法（通常由继承的框架相关类提供，比如MyBatis-Plus框架下的ServiceImpl类提供此方法）会返回对应的Mapper接口实例，
+    // 用于与数据库进行交互操作。在这里获取到PermissionMapper实例后，就可以调用它定义的deleteRolePermissionByPid方法，
+    // 其目的是依据传入的id（权限ID或菜单ID，具体依业务而定），从sys_role_permission表中删除与之相关的关联数据，
+    // 例如在权限管理系统中，可能存在角色与权限之间的关联关系存储在该表中，当删除某个权限或者菜单时，需要先清理与之关联的角色权限记录，避免数据不一致或冗余
     @Override
     public boolean removeById(Serializable id) {
 
@@ -28,6 +31,11 @@ public class PermissionServiceImpl extends ServiceImpl<PermissionMapper, Permiss
         PermissionMapper permissionMapper = this.getBaseMapper();
         permissionMapper.deleteRolePermissionByPid(id);
         //删除权限表中的数据
+        // 删除权限表中的数据
+        // 调用父类的removeById方法（super.removeById(id)），借助父类（可能是继承自通用服务层实现类）中已经实现的删除逻辑，
+        // 根据传入的id去对应的权限表（具体对应哪个表由继承关系和配置决定，通常与当前业务实体对应的表相关）中删除主体数据记录，
+        // 例如删除权限记录本身，最终返回一个布尔值表示这次删除主体权限数据操作是否成功，同时整个重写的removeById方法也会将这个布尔值作为最终结果返回，
+        // 告知调用者此次包含关联数据清理和主体数据删除的整个删除操作是否成功完成。
         return super.removeById(id);
     }
 }

src/test/java/com/yeqifu/generator/CodeGenerator.java

@@ -99,3 +99,117 @@ public class CodeGenerator {
 
 
 }
+
+// 这个类（假设所在类有合适的类名）包含了代码生成相关的逻辑，通过配置MyBatis-Plus的代码生成器，根据给定的各种参数生成相应的代码文件，
+// 比如实体类、Mapper接口、Service层、Controller层等代码，方便快速搭建项目的基础代码结构，减少手动编写重复代码的工作量。
+
+
+
+    // scanner方法，用于从控制台获取用户输入的信息，并且进行简单的验证，如果输入为空则抛出异常提示用户重新输入。
+    // 参数tip用于提示用户需要输入的内容类型，在控制台输出相应的提示信息引导用户输入。
+
+        // 创建一个Scanner对象，用于读取用户从控制台输入的内容，它会关联到标准输入流（System.in），以便获取用户输入的文本信息。
+
+        // 构建一个包含提示信息的字符串，告知用户需要输入什么内容，例如提示"请输入模块名："等，方便用户明白输入的要求。
+
+            // 获取用户输入的字符串内容，如果用户有输入的话，将其赋值给ipt变量。
+
+            // 使用StringUtils工具类（假设来自MyBatis-Plus的工具包或者项目自定义的工具类，用于字符串相关的操作）判断输入的字符串是否不为空，
+            // 如果不为空，则将该输入的字符串返回，作为有效的用户输入内容。
+
+        // 如果用户没有输入内容（即输入为空字符串或者没有输入任何东西），则抛出一个MybatisPlusException异常，
+        // 异常信息会提示用户需要输入正确的相应内容，引导用户重新进行输入操作。
+
+
+        // 代码生成器
+        // 创建一个AutoGenerator对象，它是MyBatis-Plus提供的代码生成器的核心类，通过配置它的各种属性，能够自动生成项目所需的多种代码文件。
+
+        // 全局配置
+        // 创建一个GlobalConfig对象，用于配置代码生成的一些全局属性，例如生成代码的输出目录、作者信息、生成代码后是否自动打开文件夹等。
+
+        // 获取当前项目的根目录路径，通过System.getProperty("user.dir")方法可以获取到项目所在的磁盘路径，方便后续设置代码生成的输出位置。
+
+        // 设置生成的代码文件输出目录，将代码输出到项目的src/main/java目录下，这是Java项目中存放主要源代码的常见位置，符合Java项目的代码结构规范。
+
+        // 设置代码的作者信息，这里设置为"luoyi-"，在生成的代码文件中，会在相应的位置（比如类的注释头部等）添加作者标识，方便后续代码维护时知道代码的编写者。
+
+        // 设置当代码生成完成之后是否打开代码所在的文件夹，这里设置为false，表示生成代码后不会自动打开文件夹，可根据实际需求选择是否开启该功能。
+
+        // gc.setSwagger2(true); 实体属性 Swagger2 注解
+        // 如果取消注释上面这行代码，会在生成的实体类属性上添加Swagger2注解，用于在使用Swagger进行接口文档生成和展示时，能更好地展示实体类的属性信息，方便接口调试和文档查阅。
+
+
+        // 数据源配置
+        // 创建一个DataSourceConfig对象，用于配置代码生成时连接数据库的相关信息，使得代码生成器能够获取数据库中的表结构信息，从而根据表结构生成相应的代码。
+
+        // 设置数据库的连接URL，这里配置的是连接本地MySQL数据库（localhost:3306）中的warehouse数据库，同时设置了一些连接参数，
+        // 如使用Unicode编码、不使用SSL加密以及设置字符编码为utf8，确保与数据库的正确连接以及数据的正确读取和处理。
+
+        // dsc.setSchemaName("public");
+        // 如果数据库有指定的模式名（对于某些数据库如PostgreSQL等有模式概念），可以通过这行代码设置，在这里MySQL中一般可不设置，所以注释掉了。
+        // 设置数据库驱动的名称，这里配置的是MySQL数据库的JDBC驱动名称，不过需要确保项目的依赖中已经添加了对应的MySQL驱动包，才能正确连接数据库。
+
+        // 设置连接数据库的用户名，这里设置为"root"，通常是MySQL数据库默认的超级管理员用户名，根据实际数据库的配置情况进行相应修改。
+
+        // 设置连接数据库的密码，这里设置为"123456"，同样要根据实际数据库的密码进行填写，确保能够成功连接到数据库获取表结构信息。
+
+        // 包配置
+        // 创建一个PackageConfig对象，用于配置生成代码的包名相关信息，决定了代码文件在项目中的包结构，便于代码的组织和管理。
+
+        // 通过调用scanner方法，从控制台获取用户输入的模块名，这个模块名会用于后续代码文件的包名构建以及表名前缀等相关配置，
+        // 比如可以根据不同的业务模块来生成不同包名下的代码，使代码结构更加清晰，符合业务模块划分的需求。
+
+        // 设置生成代码的顶级包名，这里设置为"com.yeqifu"，表示生成的代码文件会放在这个包及其子包下，可根据项目的实际包名规范进行修改。
+
+        // 设置Mapper接口对应的XML文件的存放位置，这里设置为"mapper.xml"，意味着生成的Mapper XML文件会放在相应的目录下，方便后续进行数据库操作的SQL语句配置。
+
+
+        // 策略配置
+        // 创建一个StrategyConfig对象，用于配置代码生成的具体策略，比如命名规则、是否使用某些框架特性、生成哪些表的代码等，决定了生成代码的具体形式和内容。
+
+        // 设置字段名和表名是否把下划线换成驼峰命名规则，这里设置为将下划线命名转换为驼峰命名，符合Java中常见的命名规范，使生成的代码变量名和类名等更加规范、易读。
+
+
+        // 设置生成的实体类继承的父类
+        // strategy.setSuperEntityClass("com.baomidou.ant.common.BaseEntity");
+        // 如果取消注释上面这行代码，可以指定生成的实体类继承自特定的父类（这里示例是"com.baomidou.ant.common.BaseEntity"），
+        // 这样可以复用父类中的一些通用属性和方法，便于统一管理实体类的公共行为和属性，可根据项目实际需求进行设置。
+
+        // 是否启用lombok
+
+        // 设置为true表示在生成的实体类中启用Lombok框架的特性，Lombok会自动为实体类生成Getter、Setter、构造函数、toString等方法，
+        // 减少手动编写这些重复代码的工作量，使实体类代码更加简洁，前提是项目中已经引入了Lombok依赖。
+
+        // 是否生成restController
+
+        // 设置为true表示生成的Controller层代码会采用RESTful风格的控制器，符合现代Web开发中常见的接口设计风格，方便前后端分离开发以及接口的调用和管理。
+
+        // 公共父类
+        // strategy.setSuperControllerClass("com.baomidou.ant.common.BaseController");
+        // 如果取消注释上面这行代码，可以指定生成的Controller类继承自一个公共的父类（这里示例是"com.baomidou.ant.common.BaseController"），
+        // 以便复用父类中的一些通用的控制器相关方法和逻辑，可根据项目中控制器层的设计需求进行设置。
+
+        // 写于父类中的公共字段
+        // strategy.setSuperEntityColumns("id");
+        // 如果取消注释上面这行代码，可以指定在生成的实体类中，哪些字段是作为公共字段继承自父类的，这里示例是将"id"字段作为公共字段，
+        // 通常用于一些具有统一主键等情况的实体类设计，根据实际项目的实体类结构特点进行相应设置。
+
+        // 设置要生成哪些表  如果不设置就是生成所有的表
+
+        // 通过调用scanner方法获取用户输入的表名信息，要求用户以英文逗号分割多个表名输入，然后将输入的字符串按逗号分割为数组，
+        // 代码生成器会根据这个数组中的表名，只生成对应表的相关代码，若不设置这行代码，则会生成数据库中所有表的相关代码，方便根据实际需求灵活控制生成的代码范围。
+
+        // 设置Controller层的映射路径采用连字符风格，例如对于一个名为"user_info"的表，生成的Controller中对应的请求映射路径可能会类似"/user-info"，
+        // 使接口路径更符合RESTful风格以及常见的URL命名习惯，便于接口的访问和识别。
+
+
+        // strategy.setTablePrefix("sys_");
+        // 设置表名前缀，这里可以根据模块名动态设置表名前缀（通过pc.getModuleName()获取模块名并添加下划线），也可以使用固定的前缀（如注释中的"sys_"），
+        // 这样在生成代码时，会根据设置的前缀来识别和处理表名，例如在生成实体类名、Mapper接口名等时会依据表名和前缀进行相应的转换和命名，方便代码与表结构的对应和管理。
+
+
+        // 将配置好的策略信息设置到代码生成器（AutoGenerator）对象中，使得代码生成器按照设定的策略来生成代码。
+
+
+        // 调用代码生成器的execute方法，启动代码生成的流程，根据前面配置好的全局配置、数据源配置、包配置以及策略配置等信息，
+        // 自动生成相应的代码文件，包括实体类、Mapper接口、Service层、Controller层等代码，快速搭建项目的代码结构。