我之前在做Loopback项目时也碰到过几乎一模一样的问题，咱们一步步拆解解决：

一、URL重复（http://https://...）的原因与修复 #

你遇到的URL格式异常，核心是redirect参数里的地址已经带了完整协议（https://），但Loopback的verify逻辑会自动在验证链接前拼接protocol，导致两层协议叠加。

看你代码里的redirect配置：

redirect: 'https://' + config.host + '/login?verified=true'

同时Loopback在user.js里的逻辑会自动拼接verifyOptions.protocol + '://' + verifyOptions.host，如果你的config.host本身没带协议，那大概率是没显式指定protocol，Loopback默认用了http，结果把http://和你redirect里的https://example...硬拼到了一起。

修复起来很简单：

• 确保config.host只存纯主机名（比如example.api.com，别带https://）
• 在options里显式指定protocol为https，同时把redirect改成仅路径：

  var options = {
    type: 'email',
    to: member.email,
    from: 'noreply@example.com',
    subject: 'Thanks for registering.',
    template: path.resolve(__dirname, '../../server/views/verify.ejs'),
    protocol: 'https', // 显式指定协议，避免Loopback用默认的http
    host: config.host, // 这里是纯主机名，不带协议和端口
    redirect: '/login?verified=true', // 只写跳转路径就行
    user: member
  };
  

这样Loopback会自动拼接出正确的https://example.api.com/xxx，不会再出现重复的协议前缀。

二、移除URL末尾的端口号 #

默认情况下，Loopback只有当端口是http默认的80或https默认的443时，才会自动隐藏端口（就是你看到的user.js里的displayPort判断逻辑）。如果你的服务用了非默认端口但又不想在邮件里显示，有两个靠谱的方案：

方案1：手动指定不带端口的host #

直接在options里把host设为不带端口的主机名（比如example.api.com），同时确保你的反向代理（比如Nginx）已经把服务端口映射到80/443，这样用户访问时不用输端口也能正常跳转。

方案2：覆盖Loopback的verify逻辑 #

既然你已经找到了user.js里的核心代码，Loopback完全支持通过模型继承+方法重写来覆盖这段逻辑：

1. 用beforeRemote钩子提前修改参数，强制清空端口：

   Member.beforeRemote('verify', function(context, unused, next) {
     const verifyOptions = context.args.options;
     // 不管当前端口是什么，都不显示
     verifyOptions.port = '';
     next();
   });
   

2. 如果你想完全自定义端口判断逻辑，也可以直接重写verify方法：

   const qs = require('querystring');
   const joinUrlPath = require('loopback/lib/utils').joinUrlPath;
   
   Member.verify = function(options, cb) {
     const userModel = this;
     const pkName = userModel.definition.idName();
     const verifyOptions = options;
   
     // 自定义逻辑：不管端口是什么，都不添加到URL里
     const displayPort = '';
     const urlPath = joinUrlPath(
       verifyOptions.restApiRoot,
       userModel.http.path,
       userModel.sharedClass.findMethodByName('confirm').http.path
     );
     // 手动拼接验证链接
     verifyOptions.verifyHref = verifyOptions.verifyHref || 
       `${verifyOptions.protocol}://${verifyOptions.host}${displayPort}${urlPath}?${qs.stringify({
         uid: '' + verifyOptions.user[pkName],
         redirect: verifyOptions.redirect,
       })}`;
     // 调用父类的原verify逻辑
     this.base.verify.call(this, options, cb);
   };
   

三、关于覆盖Loopback内置user.js逻辑的可行性 #

完全没问题！Loopback的模型系统设计就是支持扩展的——因为你的Member模型应该是继承自内置的User模型，所以你可以直接在Member模型里重写verify方法，Loopback会优先使用你自定义的逻辑，而不是node_modules里的user.js代码。

另外还有个更简单的方式：直接在options里指定verifyHref，完全跳过Loopback的自动拼接逻辑，自己定义完整的验证链接：

var options = {
  // ...其他配置
  verifyHref: `https://${config.host}/your-custom-verify?uid=${member.id}&redirect=/login?verified=true`,
  user: member
};

这样Loopback就会直接用你写好的URL，不用管它内置的拼接逻辑，自由度拉满。

内容的提问来源于stack exchange，提问作者Tony Hensler