大卫，您好，

这真的很有趣。

否，凭据在package.json中是稳定的：

" cds"：{
   "要求"：{
    " API_BUSINESS_PARTNER"：{
      " kind"：" odata"，
      " model"：" srv \\ external \\ API_BUSINESS_PARTNER"
    }
  }
 }
 

首次启动" cds watch"会导致：

>> cds监视[cds]-运行nodemon ... --ext cds，csn，csv，ts，mjs，cjs，js，json，json，properties，edmx，xml --exec cds服务所有--with- 模拟-在内存中？
 [cds]-从3个文件中加载的模型：db \ schema.cds srv \ admin-service.cds srv \ external \ API_BUSINESS_PARTNER.csn [cds]-使用来自以下位置的绑定：{注册表：'〜/.cds-services  .json'}
 [cds]-连接到sqlite db {数据库：'：memory：'}>从db \ data \ my.domain-OrderItems.csv中填充my.domain.OrderItems>从db \ data \ my中填充my.domain.Orders。  domain-Orders.csv>从db \ data \ my.domain-Products.csv中填充my.domain.Products>从db \ data \ my.domain-Suppliers.csv/>中填充my.domain.Suppliers已成功部署到sqlite中 -内存数据库
 [cds]-模拟API_BUSINESS_PARTNER {at：'/api-business-partner'}
 [cds]-提供AdminService {at：'/admin'，impl：'srv \\ admin-service.js'}
 [cds]-发起于：2815.136ms [cds]-服务器监听{url：'http：//localhost：4004'}
 [以^ C结尾] 

以^ C停止并重新启动cds watch会导致：

>> cds监视[cds]-运行nodemon ... --ext cds，csn，csv，ts，mjs，cjs，js，json，json，properties，edmx，xml --exec cds服务所有--with- 模拟-在内存中？
 [cds]-从3个文件中加载的模型：db \ schema.cds srv \ admin-service.cds srv \ external \ API_BUSINESS_PARTNER.csn [cds]-使用来自以下位置的绑定：{注册表：'〜/.cds-services  .json'}
 [cds]-连接到sqlite db {数据库：'：memory：'}>从db \ data \ my.domain-OrderItems.csv中填充my.domain.OrderItems>从db \ data \ my中填充my.domain.Orders。  domain-Orders.csv>从db \ data \ my.domain-Products.csv中填充my.domain.Products>从db \ data \ my.domain-Suppliers.csv/>中填充my.domain.Suppliers已成功部署到sqlite中 -内存数据库
 [cds]-提供AdminService {at：'/admin'，impl：'srv \\ admin-service.js'}
 [cds]-启动于：2702.617ms [cds]-服务器监听{url：'http：//localhost：4004'}
 [以^ C结尾] 

因此，第二次没有任何嘲笑发生。 停止``cds watch''并重新启动导致再次进入模拟模式，依此类推...

和往常一样，我可以想象这对Windows来说很特别。 您在Windows上测试过吗？

顺便说一句：package.json中生成的条目：

"模型"：" srv \\ external \\ API_BUSINESS_PARTNER" 

在Cloud Foundry上部署到Linux容器时，带有" \\"的路径编码是否会导致问题？ 但是也许在运行时不使用此路径...