问：
return "当前登录用户：" + request.getSession().getAttribute("name");为什么不是getparemeter("session")
答案：若要获取当前登录用户的信息，通常使用 request.getSession().getAttribute("name")，因为用户登录信息一般存储在会话中，能在多个请求间保持。而 request.getParameter("session") 是获取请求参数，不适用于获取会话中的用户信息。

问：常通过控制器接口方法接收请求参数，借助 @RequestParam 注解来获取 URL 参数或者表单数据，而不是getparameter？
答案：@RequestParam：主要用在控制器接口方法里，能让代码更简洁、易读，方便处理请求参数。
request.getParameter：适用于过滤器、拦截器等非控制器层，可在请求处理流程的早期获取参数并进行处理。

问：@RequestParam的作用和request.getparameter("xxx")一样都是在？后面的参数里中获得数据，并且getparameter还可以在post的表单数据里获得而@requestparameter还不行对吧？
答案：@RequestParam 不仅能从 URL 查询字符串（也就是 ? 后面的参数）里获取数据，也可以从 POST 请求的表单数据里获取数据@RequestParam 和 request.getParameter 都能从 URL 查询字符串和 POST 请求的表单数据里获取数据。不过，@RequestParam 是 Spring 框架提供的注解，在 Spring 项目里使用更方便，能设置默认值、指定参数是否必需等；而 request.getParameter 是 Servlet API 提供的方法，更通用，不依赖特定框架。

！！问：如果不写入cookie，那么下次再登入（关闭浏览器），session已经没有了，那就登入不了了对吗
答案：不完全正确，下面分情况分析不写入 Cookie 且关闭浏览器后再次登录与 Session 的关系。

情况一：未写入 Cookie 且使用 URL 重写
如果不使用 Cookie 存储会话 ID，服务器可以通过 URL 重写的方式将会话 ID 附加到 URL 中。这种情况下，即便关闭浏览器，只要用户访问的 URL 中携带有效的会话 ID，服务器就能识别对应的 Session。

情况二：既不使用 Cookie 也不使用 URL 重写

跨越：可以用node.js代理发送请求，并且接受服务端的response，但是最后还是服务器渲染数据，需要在response里加上这些：
跨域问题源于浏览器的同源策略，该策略要求协议、域名和端口都相同才允许跨域资源共享。网关插件处理跨域的核心在于自定义 HTTP 请求和响应头，以此绕过浏览器的同源策略限制。主要涉及以下关键响应头：

Access-Control-Allow-Origin：指定允许访问该资源的外域 URI。可以设置为具体的域名，如 https://example.com，也能通过动态获取请求头里的 Origin 字段，按需返回对应的值。若设置成 *，则表示允许所有源访问，但这种方式存在安全风险，生产环境一般不建议使用。
Access-Control-Allow-Methods：表明服务器支持的跨域请求方法，例如 GET、POST、PUT、DELETE 等。
Access-Control-Allow-Headers：指定服务器允许的请求头字段。
Access-Control-Allow-Credentials：指示是否允许客户端在跨域请求中携带凭证（如 Cookie、HTTP 认证等），值为 true 或 false。
Access-Control-Max-Age：指定预检请求（Preflight Request）的有效期，在有效期内，相同的预检请求不会再次发送。
浏览器才会认为服务器和请求时同领，需要前后端配合，
BUT：跨域是业务开发中非常常见的问题。其中最常见的原因是由于域名不匹配。这种情况一般大厂都会有专门的网关插件进行处理，业务侧无需花时间进行配置，其原理就是自定义http请求响应头跨域共享资源。
如果既不使用 Cookie 存储会话 ID，也不使用 URL 重写，关闭浏览器后再次登录，服务器无法获取之前的会话 ID，也就找不到之前的 Session。因为 Session 有过期机制，默认情况下，服务器会在一段时间（如 30 分钟）后销毁未使用的 Session。当关闭浏览器后，之前的会话 ID 没有被保存，再次打开浏览器发起请求时，服务器会认为是一个新的请求，创建一个新的 Session，而不是恢复之前的 Session。

关于登录
通常登录状态的维持不仅仅依赖 Session，还会结合其他技术，如 Token 机制。即便 Session 失效，用户可以通过重新输入用户名和密码，或者使用记住密码功能（一般通过持久化 Cookie 实现）来重新登录。

综上所述，不写入 Cookie 且关闭浏览器后，不一定就无法登录，具体取决于是否采用了 URL 重写等其他会话跟踪技术，以及系统的登录机制设计。