Spring Boot脚本前台启动时dev-https配置端口失效，默认用8080

First off, let's break down what's happening here: your background startup via nohup works perfectly (uses 8443 as configured), and running the exact command directly in the console also works—but when using your start_foreground() bash function, the server falls back to port 8080, with server.port returning an empty string in the environment (instead of null, which means it's being explicitly set to empty somewhere).

Here are the most likely culprits and fixes:

1. Parameter Parsing Issues with eval #

When you build your command as a string and run it with eval, bash can misparse arguments—especially if JVM_OPTS or SPRING_OPTS contain spaces, quotes, or special characters. Direct console execution avoids this because bash handles argument splitting natively, but eval can mangle the parameter boundaries.

Fix: Use Bash Arrays for Safe Argument Passing #

Instead of building a command string, use bash arrays to preserve each argument as a separate element. This eliminates parsing errors entirely.

First, redefine your variables as arrays in the script:

JAVACMD="java"
# Define JVM options as array elements
JVM_OPTS=("-Xmx2g" "-Xms1g")
WAR_FILE="./server.war"
# Define Spring options as array elements
SPRING_OPTS=("--spring.profiles.active=dev-https")
PID_FILE="./server.pid"
LOG_PATH="./logs"

Then update your start_foreground function to use the array:

start_foreground() {
    # Combine all arguments into a single array
    local cmd_args=("$JAVACMD" "${JVM_OPTS[@]}" -jar "$WAR_FILE" "${SPRING_OPTS[@]}")
    echo "Executing: ${cmd_args[*]}"
    # Use exec to replace the shell process (cleaner startup)
    exec "${cmd_args[@]}"
    print_log "Server is stopped."
}

You can update start_background similarly to keep consistency:

start_background() {
    # Add the PID file option to the Spring opts array
    SPRING_OPTS+=("--spring.pid.file=${PID_FILE}")
    local cmd_args=("$JAVACMD" "${JVM_OPTS[@]}" -jar "$WAR_FILE" "${SPRING_OPTS[@]}")
    echo "Executing in background: ${cmd_args[*]}"
    nohup "${cmd_args[@]}" &>"${LOG_PATH}/console.log" &
    PID=$!
    print_log "Server is started with pid \"${PID}\""
}

2. Accidental Empty server.port in Environment #

The fact that environment.getProperty("server.port") returns an empty string (not null) tells us the property is being explicitly set to empty. This usually happens if:

• An environment variable SERVER_PORT is set to an empty string in the script's context
• SPRING_OPTS accidentally includes --server.port= (with no value)

Debug Step: Print All Relevant Variables #

Add debug output to start_foreground to check for this:

start_foreground() {
    echo "Working Directory: $(pwd)"
    echo "JAVACMD: $JAVACMD"
    echo "JVM_OPTS: ${JVM_OPTS[*]}"
    echo "WAR_FILE: $WAR_FILE"
    echo "SPRING_OPTS: ${SPRING_OPTS[*]}"
    echo "SERVER_PORT Env Var: ${SERVER_PORT:-Not Set}"
    # ... rest of your function
}

If you see SERVER_PORT Env Var: (empty), look for any line in your script that might be setting export SERVER_PORT= accidentally.

3. Shell Environment Mismatch #

If your script uses #!/bin/sh instead of #!/bin/bash, some bash-specific features (like arrays) won't work, and eval behavior might differ from direct console execution (which is likely running bash).

Fix: Explicitly Use Bash #

Add #!/bin/bash at the very top of your script to ensure consistent behavior.

4. Working Directory Discrepancy #

While less likely (since other profile configs are loading), if your script runs from a different directory than your console, relative paths in your config (like key-store) might break—but that wouldn't explain the empty server.port. Still, adding echo $(pwd) in the debug step can rule this out.

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