作者回复: EnvConfig里头配置是每个环境已经明确下来的配置(一般不变)，比如根域名信息，是否启用https等。application.yaml一般放各个环境的可变配置，比方说jwt secret，DB链接字符串，这些可能会变。当然这个只是一种做法，实际EnvConfig里头的配置也可以都放在application.yaml里头，可以灵活，不必拘泥于形式。

作者回复: 1. service层的操作用try-catch包起来，很正常，生产级代码通常有很多做错误处理的代码，错误处理的原则是尽早捕获和处理，实际运行时，不出错的话，这些try-catch没有多少额外开销，出错抛异常有一定开销，但这个是必须的。当然，你也可以不捕获直接往外抛，但是有悖于尽早捕获和处理原则。 2. 会出现auditLog没有记录情况，所以一般业务操作完成就要记审计日志，另外如果因为提前抛了异常而漏掉审计日志的话，事后可以通过错误日志进行追溯，另外一般还有DB操作日志可以追溯。 3. 代码是教学参考用，可以作为样板，具体生产使用你仍然需要严格测试+扩展。 4. 除了staffjoy项目可以参考，另外最近看的这个litemall(https://github.com/linlinjava/litemall)也不错，SpringBoot开发的前后分离商城项目，后面我考虑将其改造成类似Staffjoy的微服务云原生项目，欢迎也同时关注。

作者回复: 有能力可以直接阅读课程案例项目源码，然后带着问题再看课程，这样效果更好。

作者回复: 你好，课程设计重点是微服务和云原生架构，也包括SpringBoot微服务开发和K8s容器云部署，课程案例本身是一个支持多租户的SaaS应用，所以课程稍带也讲解一些多租户和SaaS架构相关内容。anyway，谢谢你的反馈，请看完完整课程后再次给出反馈，谢谢！

作者回复: 嗯，波波一直在努力输出干货，不能保证每一课都满足你的需要，但是全部听完课程，相信一定会让你有所收获。

作者回复: 不同环境的配置可以集中到配置中心去，但是本地还是需要一些配置文件(或者环境变量)，来标识当前这个应用的环境信息，这样这个应用才能到配置中心去获取当前环境的配置。 本课程的项目的有些环境信息是编码在代码中的，这个只是课程设计的一种简单做法，实际可以将配置信息尽可能变成配置文件(本地+远程)，这样在实际生产中会更灵活。

作者回复: 硬编码是最差的，其次是本地文件配置，配置中心统一管理最好。

作者回复: 课程案例是有些硬编码的，也可以做到不硬编码，通过配置适配不同环境，具体看业务需要。

作者回复: 课程项目只是演示，实际生产项目中，需要配合一些配置治理流程，防止敏感配置信息意外泄露。比方说，k8s config/secret需由专门的管理员统一管理和发布，配置的版本控制需要严格权限管理。

作者回复: 要一分为二看，如果是开源的通用框架，当然不能和环境耦合，但是对于企业的具体应用来说，因为企业的环境一般是固定的，所以对框架进行定制，并且引入一些环境判断逻辑，让应用能更灵活适配环境，有时是难免的。通用性和企业定制(引入一定耦合性)一般很难两全，需要折衷权衡。至于对代码可维护性的影响肯定会有一点，但是抽象通用的成本可能更高。